[core-workflow] bugs.python.org-related GSoC project

[anatoly techtonik]

On Thu, Mar 12, 2015 at 9:12 PM, Ezio Melotti <ezio.melotti at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150323/bb7180f2/attachment-0001.html>