[core-workflow] Migration PEP started

anatoly techtonik techtonik at gmail.com
Sun Jan 10 03:17:37 EST 2016


On Sun, Jan 10, 2016 at 5:54 AM, Brett Cannon <brett at python.org> wrote:
> I'm developing it at
> https://github.com/brettcannon/github-transition-pep/blob/master/pep-NNNN.rst
> . I'm not posting it here as I'm still actively writing it. The only reason
> I'm mentioning it now is because the migration plan has been very roughly
> outlined, so if it  looks like I'm missing something, please let me know.

I think that the missing part is the analysis of why community (or PSF, or ...)
failed to create a streamlined development process themselves. In particular,
what steps were made to implement:

1. online code editing with patch creating through hg.python.org interface
2. HG plugin that can fetch a bugXXX patch and apply it to local copy
3. mercurial queue server to allow people to maintain their own queues of
    patches in parallel and compare between them
4. what steps were made to make "our fork of the Rietveld code review tool"
    to be the "our installation" or the "global Roundup service"
5. create testing and building infrastructure (or integrating with CI services
    such as Drone.IO) for downloading patches, making sure they applied
    cleanly and running the test suite

For simple things like "spelling in documentation" the whole thing with
patch production and attachment could be done in 6 months provided that
development for 4 people is funded (2 code, 1 frontend, 1 art).


The most important stuff - what are the current activities for PSF (or whatever)
to being raise funds to make it a paid work instead of relying on a really few
core developers and volunteers to do professional work on infra that requires
rather tight timely coordination and support?

For me, there is a more core problem inside. For example, why work under
GSoC 2015 for Roundup was not submitted upstream? Because it was not
part of the job. People have problems allocating their free time, because
time management practices at their HR departments are getting better and
better not leaving much for contributions.

I think that the core issue here is the money. The new generation talks
about startups and monetization, so if we don't address this, there is little
hope that new generation will be attracted, at least that's my observation.

I think that if PSF can help us with legal issues concerning funding open
source activities, we can construct a few teams through Gratipay and do
the development in open way. It will be more effective for Python in the
long run, because it will showcase that Python is capable of, and provide
people a playground to learn about good engineering practices. I am not
saying that this will 100% work - maybe there are things ahead that I do not
see as well, but what's drives me mad that it seems that nobody is even
trying to preserve the open source spirit in all of that.

If we will be sacrificing the open source so easily, then the next Python with
static typing will be 'Microsoft Python' or 'Facebook Python' will be rewritten
from scratch, and all credits gathered through all these years will be lost
behind the shiny name of another corporation. Sad.


More information about the core-workflow mailing list