[ADMIN] process for applying patches

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

I have a simple question, which might have wider implications though: how do
patches get applied to the source code?

I submitted a few patches in the past few weeks but received comments only on a
few of them. Are they good? Do they fit nicely in the Cocoon framework? Nobody
seems to care about this or to take any action. This is quite amazing to me, is
the first free software/open-source project I work on where people don't seem
to be preoccupied analyzing other people's patches and do something about them.

Until now Stefano was the one in charge with the management of this project.
What happens after his departure? Who is going to take the responsibility of
accepting new contributions? Successful free software and open-source projects
like the Linux kernel or the GCC compilers suite have a few individuals that
analyze the proposed patches and accept or reject them. If we want to be
successful in this project we need to setup a similar thing. I realize that
this is an open-source project and it might eat a substantial amount of time
from somebody's time to do it. But we have to find the resources to do it,
otherwise new contributions are going to be lost or people will get bored
submitting contributions nobody is analyzing.

I managed to convince the group I work in here at HP that we should use Cocoon
in some of our projects; it was a hard thing. An even harder thing was
convincing them that is worth contributing back to the project our changes. Now
that I managed to do it, hardly anybody seems to care about the contributions.
I think it would be a shame if these and any other contributions don't get at
least discussed if not accepted.

Maybe the people that have CVS commit access can come up with a way to look at
all these contributions and decide on whether they fit in the Cocoon framework
so they accept them or they don't, in which case they reject them. I strongly
feel we need to have such a process in place.

What are your thoughts on this?

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: Project coordination (was Re: [ADMIN] process for applying patches)

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

From: "Giacomo Pati" <gi...@apache.org>
> Ovidiu Predescu wrote:
> > 
> > I have a simple question, which might have wider implications though: how do
> > patches get applied to the source code?
> > 
> > I submitted a few patches in the past few weeks but received comments only on a
> > few of them. Are they good? Do they fit nicely in the Cocoon framework? Nobody
> > seems to care about this or to take any action. This is quite amazing to me, is
> > the first free software/open-source project I work on where people don't seem
> > to be preoccupied analyzing other people's patches and do something about them.
> 
> I've seen your posts and hoped someone else will have the time to look at it
> because IIRC most of them were for Cocoon 1 which I'm not dealing with. Robin
> and Donald doing that just fine.

AFAIK, if a patch is applied... well, its good! :-)

> > Until now Stefano was the one in charge with the management of this project.
> > What happens after his departure? 
> 
> Of course this is a point we have to discuss. I was asked by Stefano to take his
> place but I want the community to decide upon this. I'm knowing Cocoon 2 quite
> well but I'm not having that much free resources (mainly time) as Stefano to
> offer (approx. 2 hours/day off which almost 1 hour needed to read the mails :().
> I'm also not the guy with those many Random Thoughts [RT] and the overview over
> the XML/Java world as he was. But I've clearly commited myself to this project
> and if everybody of the commiters and users can support me I will give it a try
> and do the coordination of this wonderfull project.

IMHO, the basic thing to do now is to finish Cocoon2.
The ideas are there, the framework is there, we need to finish the implementation.
If Stefano left, I'm sure he knew we all know how to continue.
+1 for Giacomo for now, if a votation is required... are there any other "candidates"?

> > Who is going to take the responsibility of
> > accepting new contributions? 
> 
> Accepting new contribution has nothing to do with Stefano's absence or presence
> nor with project coordination. Every committer should care about them and take
> responsability to apply them.

right.
 
> > Successful free software and open-source projects
> > like the Linux kernel or the GCC compilers suite have a few individuals that
> > analyze the proposed patches and accept or reject them. 
> 
> I would think this is the same here, too. There is at least Robin and Donald
> doing that regularly for Cocoon 1 and it's me and Ross and others doing that for
> Cocoon 2 as well.

yes.

> > If we want to be
> > successful in this project we need to setup a similar thing. I realize that
> > this is an open-source project and it might eat a substantial amount of time
> > from somebody's time to do it. 
> 
> 
> > But we have to find the resources to do it,
> > otherwise new contributions are going to be lost or people will get bored
> > submitting contributions nobody is analyzing.
> 
> Yes, you are right. Speaking for Cocoon 2 and myself I haven't had the time to
> analyze many patches because most of them are dealing with peripheral stuff and
> the main concerns at the first place (IMO) is to take care of the inner
> architecture (and this is really burning under my nails). 
> 
> > I managed to convince the group I work in here at HP that we should use Cocoon
> > in some of our projects; it was a hard thing. An even harder thing was
> > convincing them that is worth contributing back to the project our changes. Now
> > that I managed to do it, hardly anybody seems to care about the contributions.
> > I think it would be a shame if these and any other contributions don't get at
> > least discussed if not accepted.
> > 
> > Maybe the people that have CVS commit access can come up with a way to look at
> > all these contributions and decide on whether they fit in the Cocoon framework
> > so they accept them or they don't, in which case they reject them. I strongly
> > feel we need to have such a process in place.
> 
> I think that we have such a process. It has worked since I contribute to the
> project. Please, if we have missed your contribute (for C2) please repost them.
> I usually mark them if they are (IMO) not that important at the moment to come
> back later on (or someone else had taken care of it already).

It has worked for me too, but it's not easy to understand open-source (for me at least
it wasn't).
Suggestions are always very welcome.

nicola_ken

Project coordination (was Re: [ADMIN] process for applying patches)

[Giacomo Pati <gi...@apache.org>]

Ovidiu Predescu wrote:
> 
> I have a simple question, which might have wider implications though: how do
> patches get applied to the source code?
> 
> I submitted a few patches in the past few weeks but received comments only on a
> few of them. Are they good? Do they fit nicely in the Cocoon framework? Nobody
> seems to care about this or to take any action. This is quite amazing to me, is
> the first free software/open-source project I work on where people don't seem
> to be preoccupied analyzing other people's patches and do something about them.

I've seen your posts and hoped someone else will have the time to look at it
because IIRC most of them were for Cocoon 1 which I'm not dealing with. Robin
and Donald doing that just fine.

> Until now Stefano was the one in charge with the management of this project.
> What happens after his departure? 

Of course this is a point we have to discuss. I was asked by Stefano to take his
place but I want the community to decide upon this. I'm knowing Cocoon 2 quite
well but I'm not having that much free resources (mainly time) as Stefano to
offer (approx. 2 hours/day off which almost 1 hour needed to read the mails :().
I'm also not the guy with those many Random Thoughts [RT] and the overview over
the XML/Java world as he was. But I've clearly commited myself to this project
and if everybody of the commiters and users can support me I will give it a try
and do the coordination of this wonderfull project.

> Who is going to take the responsibility of
> accepting new contributions? 

Accepting new contribution has nothing to do with Stefano's absence or presence
nor with project coordination. Every committer should care about them and take
responsability to apply them.

> Successful free software and open-source projects
> like the Linux kernel or the GCC compilers suite have a few individuals that
> analyze the proposed patches and accept or reject them. 

I would think this is the same here, too. There is at least Robin and Donald
doing that regularly for Cocoon 1 and it's me and Ross and others doing that for
Cocoon 2 as well.

> If we want to be
> successful in this project we need to setup a similar thing. I realize that
> this is an open-source project and it might eat a substantial amount of time
> from somebody's time to do it. 


> But we have to find the resources to do it,
> otherwise new contributions are going to be lost or people will get bored
> submitting contributions nobody is analyzing.

Yes, you are right. Speaking for Cocoon 2 and myself I haven't had the time to
analyze many patches because most of them are dealing with peripheral stuff and
the main concerns at the first place (IMO) is to take care of the inner
architecture (and this is really burning under my nails). 

> I managed to convince the group I work in here at HP that we should use Cocoon
> in some of our projects; it was a hard thing. An even harder thing was
> convincing them that is worth contributing back to the project our changes. Now
> that I managed to do it, hardly anybody seems to care about the contributions.
> I think it would be a shame if these and any other contributions don't get at
> least discussed if not accepted.
> 
> Maybe the people that have CVS commit access can come up with a way to look at
> all these contributions and decide on whether they fit in the Cocoon framework
> so they accept them or they don't, in which case they reject them. I strongly
> feel we need to have such a process in place.

I think that we have such a process. It has worked since I contribute to the
project. Please, if we have missed your contribute (for C2) please repost them.
I usually mark them if they are (IMO) not that important at the moment to come
back later on (or someone else had taken care of it already).

Giacomo

Re: [ADMIN] process for applying patches

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

On Sat, 4 Nov 2000, Peter Donald wrote:

> At 09:37  4/11/00 +1100, you wrote:
> >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.
> 
> that may be a good idea. Have a web form where you submit patches and then
> when a committer has time they go via the patch database, apply patches,
> give changes needed in code pre patch etc. There could even have patch
> voting etc ;) Of course this requires a bit of work to set up .... thou it
> may be a good chance to test cocoon (especially yet to be finalized action
> stuff). Of course someone has to step up to the plate to actually do it ;]

[crowd thins rapidly]

[nervous shuffling of feet]

Er. Okay :)

I'm off to take a long hard look at Scarab (http://scarab.tigris.org) to
see if a bug-tracking system could be modified for patch-tracking. I'd
really like other people's opinions, perhaps off-list if this is getting
off-topic.

--Jeff

> 
> 
> Cheers,
> 
> Pete
> 
> *------------------------------------------------------*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power."          |
> |       -Abraham Lincoln                               |
> *------------------------------------------------------*
> 

Re: [ADMIN] process for applying patches

[Peter Donald <do...@apache.org>]

At 09:37  4/11/00 +1100, you wrote:
>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.

that may be a good idea. Have a web form where you submit patches and then
when a committer has time they go via the patch database, apply patches,
give changes needed in code pre patch etc. There could even have patch
voting etc ;) Of course this requires a bit of work to set up .... thou it
may be a good chance to test cocoon (especially yet to be finalized action
stuff). Of course someone has to step up to the plate to actually do it ;]



Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

Re: [ADMIN] process for applying patches

[Giacomo Pati <gi...@apache.org>]

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

Re: [ADMIN] process for applying patches

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

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
> 

Re: [ADMIN] process for applying patches

[Giacomo Pati <gi...@apache.org>]

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. 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.

> 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

Re: [ADMIN] process for applying patches

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

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.

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.

Building such a system might be a nice little open source project on it's
own :)

Would all this work? Who knows.. there is no harm in trying. It's a way in
which ordinary folks can help ease the load on committers.

--Jeff


On Fri, 3 Nov 2000, Ovidiu Predescu wrote:

> I have a simple question, which might have wider implications though: how do
> patches get applied to the source code?
> 
> I submitted a few patches in the past few weeks but received comments only on a
> few of them. Are they good? Do they fit nicely in the Cocoon framework? Nobody
> seems to care about this or to take any action. This is quite amazing to me, is
> the first free software/open-source project I work on where people don't seem
> to be preoccupied analyzing other people's patches and do something about them.
> 
> Until now Stefano was the one in charge with the management of this project.
> What happens after his departure? Who is going to take the responsibility of
> accepting new contributions? Successful free software and open-source projects
> like the Linux kernel or the GCC compilers suite have a few individuals that
> analyze the proposed patches and accept or reject them. If we want to be
> successful in this project we need to setup a similar thing. I realize that
> this is an open-source project and it might eat a substantial amount of time
> from somebody's time to do it. But we have to find the resources to do it,
> otherwise new contributions are going to be lost or people will get bored
> submitting contributions nobody is analyzing.
> 
> I managed to convince the group I work in here at HP that we should use Cocoon
> in some of our projects; it was a hard thing. An even harder thing was
> convincing them that is worth contributing back to the project our changes. Now
> that I managed to do it, hardly anybody seems to care about the contributions.
> I think it would be a shame if these and any other contributions don't get at
> least discussed if not accepted.
> 
> Maybe the people that have CVS commit access can come up with a way to look at
> all these contributions and decide on whether they fit in the Cocoon framework
> so they accept them or they don't, in which case they reject them. I strongly
> feel we need to have such a process in place.
> 
> What are your thoughts on this?
> 
> Regards,
> -- 
> Ovidiu Predescu <ov...@cup.hp.com>
> http://orion.nsr.hp.com/ (inside HP's firewall only)
> http://www.geocities.com/SiliconValley/Monitor/7464/
> 
>