On Sat, 2 Jun 2018 at 14:58 Ezio Melotti <ezio.melo...@gmail.com> wrote:
> 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. > 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.
_______________________________________________ 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/
