cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [ADMIN] process for applying patches
Date Sat, 04 Nov 2000 18:05:02 GMT
Jeff Turner wrote:
> On Sat, 4 Nov 2000, Giacomo Pati wrote:
> > Jeff Turner wrote:
> > >
> > > I think this is a general problem with popular open source projects. Each
> > > project has to get the committer:contributor ratio right. Assuming Cocoon
> > > has the right ratio, but still experiences problems...
> > >
> > > A possible solution: ordinary cocoon-devvers "register" themselves as
> > > interested in certain parts of Cocoon. If you a) understand the general
> > > architecture, and b) understand what file does, register your
> > > interest. When someone proposes a patch to, those registered can
> > > review the patch. If the patch looks good, reviewers +1 it on this list.
> > > When a real committer has a chance to review the patch, they can have much
> > > more confidence in the quality of the patch. Committers can concentrate on
> > > whether a patch violates design issues, rather than simpler implementation
> > > issues.
> >
> > My personal opinion about this is that I feel it is too formal.
> It is analogous to a bug tracking system -- it formalises an existing process,
> namely that of getting patches applied. "Patch tracking" is probably a good
> name. It does add formality, but just as with bug tracking systems, that isn't
> necessarily a bad thing.
> > I think commiters and developers should automatically feel responsable
> > for parts of the system they are interested on. And if a patch gets
> > forgotten I hope those interested poeple stand up and say so on the
> > list (and not only the original contributor). Nobody is perfect but if
> > we help each other we can make it more perfect as a community not as
> > an individual.
> Well.. currently, one posts a patch to cocoon-dev, waits until a committer
> has time, and then hopes that one's patch hasn't been overlooked in the
> mass of other postings. No-one other than committers has incentive to look
> at the patch. Developers without commit access do not "automatically feel
> responsible".  There is no culture of patch-reviewing. The peer review process
> only happens after a commit.
> Yes, a "patch tracking" system is more formal, but that formalism lends
> respectability to the title "patch reviewer", and may enough start a culture
> of pre-commit peer reviewing.

Probably this is the problem. Patches posted to high traffic mailing
list easily get overlooked or forgotten. A "patch tracking system"
(apart from the mailing list) could indead be valuable. Does anybody
know such a system? Is anybody planning to do that?


View raw message