Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: giacomo
Message-ID: <3A044FCE.1337B392@apache.org>
Date: Sat, 04 Nov 2000 19:05:02 +0100
From: Giacomo Pati <giacomo@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [ADMIN] process for applying patches
References: <Pine.LNX.4.10.10011042017010.6174-100000@nescafe.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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 X.java does, register your
> > > interest. When someone proposes a patch to X.java, 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?

Giacomo