[python-committers] Comments on moving issues to GitHub

Sat Jun 2 22:49:24 EDT 2018

On Sat, 2 Jun 2018 at 14:58 Ezio Melotti <ezio.melotti at gmail.com> wrote:

> Hi,
>
> On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon <brett at python.org> wrote:
> >
> >
> > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya <mariatta.wijaya at gmail.com>
> > wrote:
> >>
> >> [SNIP]
> >>
> >>> 2. Better support for core developers in the tracker.
> >>
> >>
> >> Not sure what you mean by "support"? There are only two maintainers of
> the
> >> bug tracker, they both are also Python core developers: Brett and Ezio.
> My
> >> personal opinion is: they're more valuable elsewhere instead of
> supporting
> >> the bug tracker. At its current state, the bug tracker is not ready to
> take
> >> up new contributors, and it will not be easy effort to onboard new bpo
> >> maintainers.
> >
> >
> > I actually wouldn't list me as a maintainer of b.p.o. I only have passing
> > knowledge of the code due to reviewing Ezio's changes to support the CLA
> > bot. It used to be RDM, Ezio, and Maciej, then DRM got busy, and then
> Maciej
> > got busy with helping move our hosting over to OpenShift and off of our
> > previously free hosting provider who sold their business (I also think
> > Maciej is also busy with other things). I don't know what Ezio's
> > availability currently sits at, but I have not heard from him recently.
> >
>
> I haven't actively worked on the tracker, but I kept an eye on it and
> acting when needed (e.g. yesterday I deployed a fix committed by
> Berker :).
> If needed I can pick it up again.
>

Great! So now we're tied for GitHub and b.p.o maintenance. ;)

> It should also be mentioned that before us, MvL also used to work on
> the tracker, and he added the Rietveld and openid integration (and
> these parts are not very well maintained now).
>

Oh, the list of former contributors was not meant to be exhaustive, more
just who I could remember during the GitHub transition days.

>
> > If you look at
> > https://hg.python.org/tracker/roundup/shortlog/bugs.python.org there
> has not
> > been an update to the repo's code in 8 months but there have been
> reported
> > issues as recently as yesterday:
> > http://psf.upfronthosting.co.za/roundup/meta/ .
> >
>
> This is a bit misleading:
> * that repo is updated only when Roundup is updated otherwise it sits
> there waiting for a new release. Roundup 1.6 is going to be released
> soon;
>

Sorry about that, I just grabbed the URL the contribution docs say to work
from for Roundup and didn't notice the extra URL for configuration.

> * the repo for our instance is
> https://hg.python.org/tracker/python-dev/shortlog/default .  This also
> didn't get many commits lately, however
> * the meta tracker also didn't get many new issues.  Only 7 issues in
> the metatracker have had any activity in the last 3 months, 2 are
> about SSL failure/certificates, 3 are about email ending up in the
> spam, one is about Google auth (however I'm not familiar with that
> part of the code), and the last one is a minor issue with a simple fix
> that needs to be tested/deployed.
>
> IOW there aren't many commits because there aren't that many issues
> with the code and because Roundup 1.6 hasn't been released yet.
>
>
> As mentioned above, the Roundup team is about to release Roundup 1.6.
> This release drops support for Python <2.7.
> AFAIU the infra team wanted to move/upgrade the machine running b.p.o
> (that is currently still running Python 2.6).  When that happens (and
> once Roundup 1.6 is released) we will upgrade it.
>
>
> > IOW I consider b.p.o unmaintained ATM. Mark Mangoba and the PSF
> > infrastructure team can re-start the instance if it falls over, but no
> one
> > is working on e.g. fixing log-in issues or any of the various UX issues
> we
> > are all painfully aware that b.p.o has.
> >
> > As I said at the language summit, if people want to keep b.p.o around
> then
> > we need to get some volunteers to staff it. I personally would like to
> see
> > three people step forward and say they will work to improve b.p.o to make
> > sure it functions as expected now and plan to improve it long-term. But I
> > personally would settle for just two people actively working towards
> making
> > b.p.o a tenable solution (the three person goal is just from experience
> of
> > always wanting at least one backup even if someone goes on vacation or
> does
> > an OSS detox).
> >
>
> It depends on what kind of maintenance we need.  In its current state
> b.p.o is quite stable and requires little maintenance IMHO.
>

I would be more inclined to agree if we didn't have so many login problems
(e.g. I have needed to manually go in and set people's passwords to reset
it due to issues getting password reset emails).

> If instead we want to start adding (and fixing/maintaining) new
> features, then the situation is different.
>
> For the latter to happen, I would like to first see a PEP discussing
> what desired features GitHub has that Roundup doesn't and vice versa
> (Nick's list and Mariatta's slides and notes are a good starting
> point, but they should be consolidated and include the feedback
> expressed by other core devs on this thread).
>

I believe the plan is to have a round of proposals, including staying on
b.p.o (but I'm not driving this so I could be wrong :) .

> From there we can evaluate how difficult it would be to implement
> those in Roundup and how this will compare with the difficulty of
> switching to GitHub or some other system.
>
> I already discussed with the Roundup devs about some of the features
> listed by Nick, so I can comment on them:
>
> > <Nick's list>
> > Some examples of problems that would benefit from attention:
> >
> > - fixing the SSL/TLS connectivity issues
>
> This is also being discussed at
> https://github.com/python/psf-infra-meta/issues/4 (since it's an infra
> issue).  One of the Roundup devs recently suggested a solution that
> still needs to be tested.
>
> > - making the issue tracker usable on mobile devices
>
> The Roundup team has already some working prototype.
>
> > - ability to edit the description for issues that evolve over time, not
> just the title
> > - improved editing support for comments (both in initial formatting, and
> in being able to correct errors)
>
> Comment editing shouldn't be too difficult to implement.  (For
> "description", do you mean the first/initial message/comment?)
>
> > - REST API access to tracker data
>
> The code has been written, it needs to be merged and tested on a live
> instance.  (I'm particularly concerned about security here, since it's
> a whole new API that could expose new vulnerabilities, and even though
> care has been taken when the code was written, I'm no security expert
> and I would like if someone tried to break it in ways I'm not yet
> aware of).
>
> > - simplifying account creation (especially for folks that already have
> GitHub accounts)
>
> Adding GitHub login to b.p.o should be doable too.
>
> > - rationalising the metadata fields by asking which ones actually see
> significant use
>
> These have been discussed and changed several times over the years.
> With the REST API it will be easier to gather better usage stats.
> FWIW there are some notes and ideas about it at
> https://wiki.python.org/moin/TrackerDevelopmentPlanning#workflow and
> https://wiki.python.org/moin/DesiredTrackerFeatures
>
> > </Nick's list>
>
> > But as of right now we have zero people supporting b.p.o (and GitHub has
> one
> > with Mariatta which puts GH ahead in my book). Because of this, in my
> > opinion this discussion shouldn't include b.p.o as an option until those
> > volunteers materialize. We can argue GitHub versus GitLab versus some
> other
> > issue tracker (open or closed source, self-hosted or service-hosted I
> > personally don't care; heck write it from scratch like Warehouse if
> that's
> > what it takes), but unless we get some people to step forward to help
> with
> > b.p.o then I personally consider it our temporary solution until we
> figure
> > out where we're going next with b.p.o and not a viable option in this
> > discussion.
> >
>
> Even if the volunteers don't materialize (and I dematerialize), we
> still have to determine if the cost of keep using b.p.o as is, is
> greater than the cost of moving everything to a new system.
>

Yep.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180602/a7f382cc/attachment.html>