Release and Commit Policies

[Dr Andrew John Hughes]

On 12:01 Thu 12 May     , Jiri Vanek wrote:
> On 05/12/2011 03:50 AM, Dr Andrew John Hughes wrote:
> >> http://icedtea.classpath.org/wiki/ReleasePolicy
> >> http://icedtea.classpath.org/wiki/CommitPolicy
> >>
> >> These are largely explicit documentation of our current processes,
> >> but comments are welcomed.
> >>
> >> As specified on the wiki, don't make changes to these documents
> >> without first discussing it either or on the Discussion page.
> >>
> >> I also updated the Main page:
> >>
> >> http://icedtea.classpath.org/wiki/Main_Page
> >>
> >> to cleanup the contributing section and link to these documents.
> 
>  >"The review process should continue until all parties are happy with 
>  >the patch."
> 
> This is very dangerous  - one single person can block patch then (maybe 
> uninterested person?) . Even when it is reviewer himself, then there is 
> no judge when two _opinions_ (just! opinions) are standing  against each 
> other.
> 

My point here was inspired by current events i.e. don't go and commit a patch
which there is still ongoing discussion.

The issue you raise is a difficult one that really rolls out on a
case-by-case basis.  I don't think the situation you described is what
any of us want, but also I don't think we want patches being committed
to which there is clear disagreement.

I guess such cases have to be resolved by involving more than two people and
getting a majority consensus.  Does that sound suitable?

>  > " Unless otherwise stated by the reviewer"
> 
> This in contradiction with previous sentence. When reviewer said It 
> looks ok then possible it can not be stopped by someone else 
> (afterwards? Or overlap someone else "against" hints?) ?
> 

That's possible.  This section probably needs to be expanded to:

"The review process should continue until the majority of reviewers
are happy with the patch.  Where there is divided opinion, the input
of other developers should be sought in order to allow the discussion
to reach an appropriate conclusion.  The review process may involve
several revisions of the patch being posted, in order to rectify any
perceived shortcomings.  Unless otherwise stated by the reviewer, it
should be assumed that the new version of the patch should be posted
and an acknowledgement acquired before the patch is committed."

Does that help?

> 
>  > "it should be assumed that the final version of the patch should be
>  > posted and an acknowledgement acquired before the patch is committed."
> 
> Does it really only _should_ ??
> 
> 
> Regards J.

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37