cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: [ADMIN] process for applying patches
Date Sat, 04 Nov 2000 10:37:13 GMT


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. 


--Jeff

> 
> > To implement this system, we could set up a web site where people register
> > themselves as reviewers, and indicate which files they are interested in.
> > Then if I modify X.java, I can look up who's registered as reviewers and
> > send the patch to them (in addition to cocoon-dev). There can be an online
> > voting system, where reviewers who do their job well get recognised
> > (possibly leading to commit access), and those who don't get automatically
> > removed after a few -1's. The whole system can work without any
> > intervention from the cocoon maintainers.
> 
> What do others think about such a formalism?
> 
> Giacomo
> 


Mime
View raw message