[Idle-dev] IDLE contributors and committers

Antoine Pitrou solipsis at pitrou.net
Sun Jul 18 17:59:09 CEST 2010


On Sat, 17 Jul 2010 17:57:34 +0300
Tal Einat <taleinat at gmail.com> wrote:
> 
> However, in the long run just allowing "heavy" contributors such as
> myself commit rights won't be enough. There's definitely a need for
> one or more active maintainers of IDLE who can take care of incoming
> bug reports and patches. We may hope that at least one serious
> contributor who is given commit rights will take up this position
> naturally, but perhaps a more active approach would be beneficial?

Well, the general problem can be solved stepwise.
Here (since this discussion happens both on python-dev and idle-dev), I
think we are firstly interested in how python-dev can allow IDLE
development and maintenance to happen again. Hence my proposal for IDLE
contributors to become committers.

Then, idle-dev can do further proposals (for example, a dedicated IDLE
development FAQ or manual, etc.).

> I also think that there is a need for a guiding hand for IDLE, as
> Guido is for Python. It took a bit of time until I "got" the goals and
> principles of IDLE (e.g. easy to learn, minimal and obvious interface)
> by having KBK explain them in detail and explain the drawbacks of
> certain proposed changes. Having some kind of central authority is
> especially important in order to keep IDLE on track because the active
> development of IDLE is slow and done by various contributors -- there
> is currently no central group of active developers making such
> decisions. This doesn't have to be one person who also takes care of
> bugs, patches and testing, it could be someone who is just readily
> available via the idle-dev mailing list and keeps up with development
> of IDLE.

Or it could be several persons. "The IDLE maintainers", or "the IDLE
committers".

> Going along these lines of thought, I reach my original conclusion:
> IDLE is somewhat a project of its own. Perhaps considering IDLE a
> daughter-project of Python is appropriate, and continuing to develop
> it as part of the Python codebase could be reasonable, if more active
> maintainers can be found. I certainly support continuing to package it
> as part of the standard distribution.

The thing is, if we package it as part of the standard distribution:
- IDLE development has to follow the release schedule (bugfix-only
  period, code freeze, etc.)
- IDLE issues have to be considered Python issues, in that they affect
  the overall quality of Python (as perceived by users)

Therefore, it would probably be counter-productive for IDLE to have a
totally separate development environment (VCS, issue tracker) where the
only communication with python-dev takes places before a new Python
release.

Regards

Antoine.




More information about the IDLE-dev mailing list