Re: [ADMIN] process for applying patches

[Ovidiu Predescu <ov...@cup.hp.com>]

On Sat, 04 Nov 2000 19:05:02 +0100, Giacomo Pati <gi...@apache.org> wrote:

> Jeff Turner wrote:
> > 
> > On Sat, 4 Nov 2000, Giacomo Pati wrote:
> > 
> > > Jeff Turner wrote:
> > > >
> > > 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?

I think setting up a separate mailing list, cocoon-patches, for posting and
reviewing patches might be good enough. From my experience as the Objective-C
maintainer in the GCC compiler suite for the last 3 years, this works fine even
with a high volume of patches. Setting up a Web site to track patches might
also help, although I don't think is essential.

I also think would be really useful to publish the list of the current people
that have CVS commit rights together with their area of expertise in Cocoon.
This way somebody that has a patch can directly contact the right person and
Cc: the mailing list for patch review. Check-out the MAINTAINERS file in GCC
for an example of this:

http://gcc.gnu.org/cgi-bin/cvsweb.cgi/egcs/MAINTAINERS?rev=1.121&content-type=text/x-cvsweb-markup

As Jeff Turner mentioned before, the GCC model works well because GCC reached a
certain critical mass in terms of contributors and active developers. I'm sure
as Cocoon matures, things will become smoother. Right now is just a little
annoying as there's no defined way to have changes incorporated in the main
trunk.


Regards,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/

Re: [ADMIN] process for applying patches

[Nicola Ken Barozzi <ni...@supereva.it>]

----- Original Message -----
From: "Ovidiu Predescu" <ov...@cup.hp.com>
To: <co...@xml.apache.org>
Sent: Monday, November 06, 2000 6:19 AM
Subject: Re: [ADMIN] process for applying patches


> On Sat, 04 Nov 2000 19:05:02 +0100, Giacomo Pati <gi...@apache.org>
wrote:
>
> > Jeff Turner wrote:
> > >
> > > On Sat, 4 Nov 2000, Giacomo Pati wrote:
> > >
> > > > Jeff Turner wrote:
> > > > >
> > > > 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?
>
> I think setting up a separate mailing list, cocoon-patches, for posting
and
> reviewing patches might be good enough. From my experience as the
Objective-C
> maintainer in the GCC compiler suite for the last 3 years, this works fine
even
> with a high volume of patches. Setting up a Web site to track patches
might
> also help, although I don't think is essential.

IMHO +1 (informal vote)
The list is really crowded

> I also think would be really useful to publish the list of the current
people
> that have CVS commit rights together with their area of expertise in
Cocoon.
> This way somebody that has a patch can directly contact the right person
and
> Cc: the mailing list for patch review. Check-out the MAINTAINERS file in
GCC
> for an example of this:
>
>
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/egcs/MAINTAINERS?rev=1.121&content-typ
e=text/x-cvsweb-markup

-1 everyone should feel responsible.
the code should be maintained by all, also to mature in knowledge.
Ok, it is not what you said, but if people start contacting coders
directly...
it's definately not ok IMHO. If someone has expertise and time, he
will answer, period.


> As Jeff Turner mentioned before, the GCC model works well because GCC
reached a
> certain critical mass in terms of contributors and active developers. I'm
sure
> as Cocoon matures, things will become smoother. Right now is just a little
> annoying as there's no defined way to have changes incorporated in the
main
> trunk.

As Giacomo pointed out, time is never enough ;-)
Right now I am oberated with work, maybe next month I can contribute more
actively again. I made the error stuff in C2; if it had problems and people
would
start sending me questions, what could I do?
What do you think?

nicola_ken :-)

Re: [ADMIN] process for applying patches

[Jeff Turner <je...@socialchange.net.au>]

On Sun, 5 Nov 2000, Ovidiu Predescu wrote:
[snip]
> > 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?
> 
> I think setting up a separate mailing list, cocoon-patches, for posting and
> reviewing patches might be good enough. From my experience as the Objective-C
> maintainer in the GCC compiler suite for the last 3 years, this works fine even
> with a high volume of patches. Setting up a Web site to track patches might
> also help, although I don't think is essential.

Dermot McGahon mentioned that the linux kernel list have recently adopted
a patch filtering system
(http://kt.linuxcare.com/kernel-traffic/kt20000925_86.epl#11)

All patches get sent to kernel-patches@kernel.org, and after some validity
checks, each patch gets assigned an ID and posted to linux-kernel.

The proposer, Dan Quinlan, had this to say of a separate mailing list for
patches:

"We had some amount of discussion about whether a separate mailing list
woul be a good idea, but we ruled the idea out because fragmenting the
kernel-related discussion would have negative effects on development. If
it becomes a problem, we can always separate it later. "

> 
> I also think would be really useful to publish the list of the current people
> that have CVS commit rights together with their area of expertise in Cocoon.
> This way somebody that has a patch can directly contact the right person and
> Cc: the mailing list for patch review. Check-out the MAINTAINERS file in GCC
> for an example of this:
> 
> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/egcs/MAINTAINERS?rev=1.121&content-type=text/x-cvsweb-markup

A good idea IMHO, but it could become a maintenance headache, especially
keeping the "areas of expertise" section up-to-date. One tends to pick up
this info just by hanging around on the list for a while.

Btw, due to a "feature" of CVS, one can view the CVSROOT of any project.
Checking out Cocoon's CVSROOT yields lots of interesting stuff, including
the file CVSROOT/avail, which contains the access control list for who's
got commit access.

Except it doesn't have cocoon. So the previous paragraph was pointless ;P
It's still an interesting fact to know.

--Jeff


> As Jeff Turner mentioned before, the GCC model works well because GCC reached a
> certain critical mass in terms of contributors and active developers. I'm sure
> as Cocoon matures, things will become smoother. Right now is just a little
> annoying as there's no defined way to have changes incorporated in the main
> trunk.
> 
> 
> Regards,
> -- 
> Ovidiu Predescu <ov...@cup.hp.com>
> http://orion.nsr.hp.com/ (inside HP's firewall only)
> http://www.geocities.com/SiliconValley/Monitor/7464/
> 
>