[Python-Dev] Encouraging developers
phil at riverbankcomputing.co.uk
Tue Mar 6 10:06:22 CET 2007
On Tuesday 06 March 2007 6:15 am, Raymond Hettinger wrote:
> [Phil Thompson]
> > I think a lot of people care, but many can't
> > do anything about because the barrier to entry is too great.
> Do you mean commit priviledges? ISTM, those tend to be
> handed out readily to people who assert that they have good use for them.
> Ask the Georg-bot how readily he was accepted and coached. IMO,
> his acceptance was a model that all open source projects should aspire to.
> If you meant something else like knowing how to make a meaningful patch,
> then you've got a point. It takes a while to learn your way around the
> source tree and to learn the inter-relationships between the moving parts.
> That is just the nature of the beast.
I meant the second. While it may be the nature that doesn't mean that the
situation can't be improved.
> >> While submitting patches is good, there's a lot more to it than just
> >> submitting the 5-line code change to submit a bug/feature, and reviewing
> >> takes a lot of time and effort.
> > So there is something wrong there as well.
> I have not idea what you're getting at. Martin's comment seems
> accurate to me. Unless it is a simple typo/doc fix, it takes
> some time to assess whether the bug is real (some things are bugs
> only in the eye of the submitter) and whether the given fix is the
> right thing to do.
> Of course, automatic acceptance of patches would be a crummy idea.
> There have been no shortage of patches complete with docs and tests
> that were simply not the right thing to do.
My point is simply that the effort required to review patches seems to be a
problem. Perhaps the reasons for that need to be looked at and the process
changed so that it is more effective. At the moment people just seem be
saying "that's the way it is because that's the way it's got to be".
> > The process needs
> > to keep people involved in it - at the moment submitting a patch is
> > fire-and-forget.
> Such is the nature of a system of volunteers. If we had full-time people,
> it could be a different story. IMO, given an 18 month release cycle,
> it is perfectly acceptable for a patch to sit for a while until someone
> with the relavant expertise can address it. Even with a tests and docs,
> patch acceptance is far from automatic. That being said, I think history
> has shown that important bugs get addressed and put into bug fix releases
> without much loss of time. When Py2.5.1 goes out, I expect that all known,
> important bugs will have been addressed and that's not bad.
Then perhaps getting a full-time person should be taken seriously.
More information about the Python-Dev