Hi, On Sat, Jun 2, 2018 at 10:26 PM, Brett Cannon <br...@python.org> wrote: > > > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya <mariatta.wij...@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. 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). > 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; * 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. 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). >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. Best Regards, Ezio Melotti _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
