Would it be possible to get a database(s) download of all of the b.p.o. data (redacting privacy information if needed)?
I would like to work on a proof of concept using the scientific python stack, particularly Pandas, to see if we can do a GitHub/GitLab (pick your favorite) for all new issues and a front end (Flask, Django, Pyramid, etc.) for historical data. This would be much easier to do with access to the underlying data. > On Jun 2, 2018, at 1:26 PM, Brett Cannon <br...@python.org > <mailto:br...@python.org>> wrote: > > > > On Sat, 2 Jun 2018 at 12:47 Mariatta Wijaya <mariatta.wij...@gmail.com > <mailto: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. > > If you look at https://hg.python.org/tracker/roundup/shortlog/bugs.python.org > <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/ > <http://psf.upfronthosting.co.za/roundup/meta/> . > > 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). > > 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. > _______________________________________________ > python-committers mailing list > python-committers@python.org <mailto:python-committers@python.org> > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/
_______________________________________________ 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/
