[Python-Dev] Encouraging developers

[Neal Norwitz]

On 3/7/07, Facundo Batista <facundo at taniquetil.com.ar> wrote:
> A.M. Kuchling wrote:
>
> > FWIW, I have a related perception that we aren't getting new core
> > developers. These two problems are probably related: people don't get
> > patches processed and don't become core developers, and we don't have
> > enough core developers to process patches in a timely way.  And so
> > we're stuck.
> >
> > Any ideas for fixing this problem?
>
> I think that there's a barrier entry: there's no place to ask for help
> on silly problems when you're trying to help (!).
>
> Let me explain my bad english wording, with an example. Yesterday night
> I started modifying socket.py and test_socket.py. "Of course", I said,
> "let's see if the tests pass ok *before* start changing anything".
>
> Went to ~/devel/reps/python/trunk/Lib, and made:
>
>   $ python2.5 test/test_socket.py    ...   Wrong!
>
> Damn! Tried a lot of stuff...
>
>   $ cd test
>   $ python2.5 test_socket.py    ...   Wrong!
>   $ python2.5 regrtest.py test_socket ... Wrong!
>   $ python2.5 regrtest.py test_socket.py ... Wrong!
>   $ python2.5 regrtest.py socket ... Wrong!
>
> And thousand more combinations. The best I could do is actually execute
> the tests, but python was getting the installed socket module, and not
> the repository socket module (even that I was in the same directory of
> the latter).
>
> I didn't know what to try. I was stuck. This never happened to me when
> working on Decimal. What went wrong in my head in the middle?
>
> I finally understood the problem, and build python from the repository,
> and made the tests from *this* python (actually, this was an easy step
> because I'm on Ubuntu, but *I* would be dead if working in Windows, for
> example).
>
> Ok. *Me*, that I'm not ashame of asking what I don't know, if I didn't
> resolve it I'd finally asked in python-dev. But how many people would
> have throw the towel withoug getting so far?
>
> How many people want to submit a patch, or even a bug, or finds a patch
> to review, but don't know how to do something and thinks that python-dev
> is not the place to ask (too high minds and experienced people and
> everything)?
>
> What I propose is a dedicated place (mailing list, for example), that is
> something like a place where you can go and ask the silliest questions
> about helping in the developing process.
>
> - How can I know if a patch is still open?
>
> - I found a problem, and know how to fix it, but what else need to do?
>
> - Found a problem in the docs, for this I must submit a patch or tell
> something about it? How?
>
> - I found an error in the docs, and fixed it, but I'm spanish speaker
> and my english sucks, can I submit a patch with bad wording or I must
> ask somebody to write it ok?
>
> Me, for example, has an actual question to this list: "How can I know,
> if I change something in the doc's .tex files, that I'm not broking
> the TeX document structure?".

I think this was answered in a separate thread, but I want to make
sure everyone sees it here.

In addition to the buildbots that run on every checkin (more or less),
Misc/build.sh runs every 12 hours.  This script does a full build,
make install, runs the regression test suite *with refleak checking*,
and builds the docs.  Any errors are sent to python-checkins.  The
results from building the docs are here:

    http://docs.python.org/dev/  - for the trunk (ie, currently 2.6)
    http://docs.python.org/dev/2.5/

The results from running Misc/build.sh are found by adding results/ to
either of the URLs above.  If the doc doesn't build, the development
versions of the doc are not overwritten.

So to answer your question, you will know if you break a test or
documentation by following python-checkins.  Here is an example of
when a refleak was detected:

    http://mail.python.org/pipermail/python-checkins/2007-February/058689.html

Here's an example of when there was a doc failure:

    http://mail.python.org/pipermail/python-checkins/2006-February/049409.html

I've tried to make it hard to screw up Python and not notice.  The
easiest way to do it now is to check in something without a test.  If
everything is checked in with a test, it will be very hard to screw
something up and for it to not be noticed by some automated system.
It would also be nice to run texcheck.py in build.sh to catch things
like unbalanced parens.

n