[Python-Dev] Becoming a python contributor

[Martin v. Loewis]

Gustavo Niemeyer <niemeyer@conectiva.com> writes:

> At the same time, I've seen Guido and others bothered a few times
> because of the lack of man power. So the question is: how do I, a
> developer which feels capable of helping in python's development, can
> get some of the tasks which take your time out of your hands? Or even,
> how is it possible to improve some part of the development process by
> giving people like me some instructions? 

To me, the most important aspect I'd like to hand off is the review of
patches; to Tim, it is the analysis of bug reports.

There is an ever-growing backlog of both of these (atleast for
patches, we are in the state where just less than 100 are pending, so
it's not that badly growing).

It is clearly unsatisfying for submitters of both patches and bug
reports if they don't hear anything. While some of these issues are
tricky and require expertise not everybody might have, I'd still like
to see more people getting involved with that.

For reviewing of patches, I'd suggest the following guidelines:

- start with the oldest patches, and work forward to the more recent
  ones (the most recent ones are regularly checked by several people,
  and applied or rejected if a quick decision is possible - but
  some of these slip through)

- for each patch, try to find out if it
  a) is present (if not, post a notice saying that the upload is missing),
  b) applies to the Python source code cleanly (if not, either update the
     patch yourself, or request that the submitter does that),
  c) does what it says it does (no detailed analysis necessary yet)
     (if it is not clear what the patch does, or how it does that,
      request clarification);
  d) is appropriate for inclusion, by comparison to other features
     that are already in Python (if not, ask submitter for a rationale
     why this patch should be included, pointing out your objections),
  e) has undesirable side effects (if yes, ask the submitter for
     an evaluation why these side effects are acceptable),
  f) is complete (new features need documentation, bug fixes need 
     regression test cases if possible),
  g) is correct: try compiling it to see whether it works, try to come
     up with boundary cases to see whether it still works, inspect
     it to see if you find any flaws...

- if you find problems with the patch, post a note asking for
  correction.  If you find there is already a note and the submitter
  hasn't acted for quite some time (10% of the entire life of the
  patch on SF), set a deadline at which time it will be rejected.
  If there is already a commentary from the submitter, re-perform the
  entire analysis.

- If you find that you are not qualified to review the patch, still
  try to perform as many steps as you can. Don't hesitate to ask the
  submitter to explain things to you that you don't understand.

- If you complete evaluation, propose rejection or acceptance. From
  time to time, post a list of patches that you think we should act
  upon. If I find your analysis convincing, I'll execute the proposed
  action quickly.

For bug reports, a similar procedure applies. Check:
- if the bug report is reproducable,
- whether this is a bug at all, or perhaps a misunderstanding on the
  part of the submitter, and the documentation clearly says otherwise,
- if there is a patch included, analyse the patch,
- if there is no patch, but you can see how the bug would be fixed,
  ask the submitter (politely) whether he would like to write a patch,
- see whether you can write a patch yourself.

If you can't create a patch, dealing with a bug report might be
tricky. If you can see a solution, but can't work on it, post your
analysis into the bug report. If you think the bug is unfixable,
explain this as well. If fixing the bug requires expertise that you
know has, ask the submitter of who might have this expertise
(especially when it comes to strange systems).

> Also, isn't it easy to point out what's wrong in a commit from
> someone who is following the development process for a while than
> taking the time to review its code in the sourceforge patch system?

I'm not sure what you are proposing here? That all patches are just
applied, and then backed-out if incorrect?

While this may be appropriate sometimes, I think it would cause to
many disturbances. It happens from time to time that people reading
python-checkins find problems by inspection. More often, they find
problems some time afterwards, because of unexpected side effects.
This is a good thing, and it is possible only because the patches had
been reviewed carefully on SF.

> My feeling is that the Python development is currently overly
> centralized, and that you might be suffering from that now, by being
> unable to handover some of your tasks to someone else.

I agree with your first observation, but disagree with the second:
there are plenty of tasks that could be handed over. There are just no
volunteers to perform these tasks.

> I feel that everytime I send a patch, besides being contributing,
> I'm also overloading you with more stuff to review and comment and
> etc. Perhaps the fallback costs for some wrong commit is too high
> now (did I heard someone mentioning subversion?)?!

It's not that. Patches *must* be reviewed, or else they would be just
incomplete: people might commit the patch, but fail to commit the
documentation. Then, for a couple of years, there would be no
documentation. Likewise for test cases. That the patch works is alone
not good enough.

It is time-consuming to produce high-quality software. However, that
should not alone be a reason to give up the high standards of Python
development.

Regards,
Martin