On Thu, Mar 12, 2015 at 9:12 PM, Ezio Melotti <ezio.melo...@gmail.com> wrote: > Hi, > Since the PSF is looking for ideas and mentors for Google Summer of > Code, I was thinking about proposing and mentoring a project that aims > at further improving our bug tracker. > > I'm writing to core-workflow in order to understand what features we > want and which ones have higher priority, so that I can put together a > coherent proposal.
I have a quite coherent vision about that, and my opinion is that creating a flexible system around working Python infrastructure is not less important than implementing the stuff as a project. > There are currently two PEPs that are proposing changes to our infrastructure: > * PEP 462 - Core development workflow automation for CPython > (https://www.python.org/dev/peps/pep-0462/) > * PEP 474 - Creating forge.python.org > (https://www.python.org/dev/peps/pep-0474/) If there is an opportunity to have a person who will be dedicating his/her full time to integrate the latest news in software development practices from academia, then instead of going with waterfall model of: [ ask questions ] -> [ get a plan ] -> [ build a site ] <--------------------- GSoC 2015 ---------------------> https://en.wikipedia.org/wiki/Waterfall_model#Criticism Let a person try alternative development methodology and try it over a few rounds with flexibility that allows to change the result in the middle. [check]->[design]->[build]->[check]->[design]->[build]->[check]->... <-------------------------- GSoC 2015 --------------------------> > These proposals will likely require changes to the bug tracker if we > want to have a solid integration with the new tools and they might > make for a good project, however it might still be too early to know > what we will actually need. Yes, it is really hard to know what is needed without trying, so planning exact changes beforehand may lead to a system that will not be used as much. > There are other changes that have been proposed in the past, in particular: > * Some features previously discussed on this ML and summarized at > https://wiki.python.org/moin/TrackerDevelopmentPlanning > * Some other miscellaneous features listed at > https://wiki.python.org/moin/DesiredTrackerFeatures > * Better integration with Rietveld (e.g. add messages to roundup > when someone posts a review) > * Smarter branch detection in patches (sometimes patches don't get > the review link) > * Patch analysis (information such as affected files could be > extracted from the files and used by Roundup) Proof of concept is done, needs transforming pydotorg a bit to automate maintenance process and integrate with Roundup UI. https://bitbucket.org/techtonik/python-stdlib > * Reviewing and applying patches submitted on the meta-tracker > * Fix other issues listed on the meta-tracker > > These (or a subset of these) might also make for a good project, > albeit less focused. > > After discussing with Nick on IRC about this, I also sent an email to > roundup-devel about another possible project to be developed by > Roundup under the umbrella of the PSF: adding a RESTful interface (see > http://issues.roundup-tracker.org/issue2550734). This will also help > us with any future work might want to do to integrate our bug tracker > with other tools. > > If you have any feedback let me know. Right now we have the problem that Roundup UI work barrier is to high due to the usage of TAL that is not as known and popular as Jinja2/Django style templates (researching this could be a great opportunity to get an analyst position in any top company). And then there is a big encoding problem with Roundup and Jinja2 (which is already there). Jinja2 uses unicode internally, Roundup stores data in DB in "utf-8", but Python still uses "ascii" internally, so when internationalized "utf-8" input goes from web to Roundup and (without saving to DB) to Jinja2, the Jinja2 chokes. For me the obvious solution (after meditating over it for some weeks) is to release Python 2.8 with "utf-8" strings, or enable "per module encoding" in it or I don't know. Because Armin said that it it impossible to hack Jinja2. https://stackoverflow.com/questions/28642781/hack-jinja2-to-encode-from-utf-8-instead-of-ascii So, solving that problem alone could be a useful outcome of GSoC project. -- anatoly t.
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
