Re: [Ganglia-developers] STATUS file etiquette

[Carlo M. A. B. <ca...@sa...>]

On Mon, Sep 15, 2008 at 07:22:27PM -0400, Jesse Becker wrote:

> A few of us (Bernard, Brad Nicholes, and myself) were musing on IRC
> about the etiquette of STATUS file edits.

since I did 55.4% of the commits to the 3.1 STATUS file and all the
other committers except for Martin (2.7%) were part of that IRC meeting,
guess this was directed at me.

before going forward, I would like to say that I think we probably have
more important things to muse about, and the way we handle the STATUS file,
which is only a tool (an IMHO a bad one at that) for coordinating our
development, shouldn't be that big of an issue as it might seem to be, based
on recent emotive comments in emails and this IRC meeting which somehow is
labeling this simple process as requiring some sort of "etiquette".

> We decided that this is
> better discussed on the wider list, and I was volunteered to broach
> the issue (lucky me).

in our wiki under the section of communication it is suggested that
decisions made on IRC be summarized to the list as shown by :

  http://ganglia.wiki.sourceforge.net/ganglia_project

> So to get things started, here are a few things
> that *I* think would be useful.  These are suggestions only--I'm in no
> position to dictate anything to anyone.
> 
> Suggestion 1)  The +1, +0 and -1 votes get one line apiece, for a
> total of 3 lines. See below for an example.

+1

funny you mention it was your idea though since that was the way that
it was documented to work before as reflected by the template until this
commit reformatted all entries differently :

------------------------------------------------------------------------
r1716 | hawson | 2008-08-22 21:15:21 -0700 (Fri, 22 Aug 2008) | 3 lines

* Added reviews to a number of proposed backports.
* split a few +1 lines that contained multiple users into multiple +1 lines

------------------------------------------------------------------------

I'll assume we are now in consensus then since everyone that had ever cast
a vote already discussed this issue and would suggest then that the wiki
be updated to reflect this in :

  http://ganglia.wiki.sourceforge.net/ganglia_works

I really don't care if someone later decides to come out with a "-0" or to
put a comment in the vote line forcing other people to have 1 more line.

I really hope we don't have to discuss this any further as all this is
supposed to mean (regardless of if we are in election year in the US) is
that someone has verified that some patch does what it is expected of doing
or thinks that it should be improved further or maybe even reverted
completely.

> Suggestion 2)  Don't mess with other people's votes.

-1

votes are attached to patch proposals and so if the proposal changes the
vote has to be recasted (indeed we talked about this in our ganglia meeting
in groundworks)

if the vote was "-1" and the "issue" is fixed with a new patch there is
no reason not to delete the comment and the negative vote, so that it can
be voted again.

if the proponent finds a problem with his original proposal and changes it,
keeping the "+1" votes on it will be incorrect as what was verified was
something different to what the vote is attached to.  the only logical
course of action should be to remove the vote so that it can be voted again.

> Suggestion 3)  A vote of +1 does not need comment.  If committing a
> vote of +0 or -1, a comment as to why is *strongly* encouraged.

+1 with comments

the wording used slightly contradicts the "Decision Making" section on our
wiki for "Project Administration"

  http://ganglia.wiki.sourceforge.net/ganglia_project

"-1" MUST have a comment that explains clearly why the current proposal
needs more work before backported and ideally the missing pieces or an
alternative proposal contributed.

it is also important to note that a backport rejection that says something
like "I don't like this, I think we should do it differently" should also
take into consideration that trunk is already changed to what the proposal
was suggesting and so an alternative proposal MUST be contributed and
hopefully a broad discussion started.

most of the time though, I would expect discussion will be started
directly in trunk and even before the patch is proposed for backport,
after all trunk is under CTR rules and the "R" there means "REVIEW".

in any case leaving a note explaining what the problem is and starting
a discussion on how to fix it is MANDATORY and not only "strongly encouraged"

> The comment can be either on the voting line, or immediately after the
> stanza.  See below for an example.

-1 

as explained above this could be problematic for keeping the votes in
only 3 lines so it might be better avoided, if only so that we don't
have to waste time discussing this any further.

> Suggestion 4)  When a backport has been accepted, move the entire
> stanza into a CHANGES file (or something similar), along with a date
> stamp..  This should be done when the changes are actually committed
> to that branch, not when the votes are cast.  This also means that a
> CHANGES file needs to be created.

-1

in ganglia the ChangeLog is generated automatically from the commit
messages, which usually contain all relevant information about the
change which will have to be otherwise duplicated into the CHANGES file
for no good reason.

for a list of features that are to be considered part of this release,
there is already a section in the STATUS file to be maintained.

> So, any thoughts or comments?  These are, as a I said, suggestions
> only.  I'm quite willing to be convinced of other behavior.

Suggestion 5) If no votes are obtained for a proposal after 1 week it
will be assumed to be approved and committed with only 1 vote.

Suggestion 6) No discussion should be done in the STATUS file, if there is
something to say about a proposal that should be done in the list so it
can be discussed openly and decided upon effectively.  This contradicts our
wiki page and will need to be updated there too if agreed into but should help
to avoid deadlocks in non-issues as observed with some proposals which seem to
be bike shed candidates (*)

Suggestion 7) A proposal with no votes will be considered a work in progress
and shouldn't be voted with "-1".  Anyone should be able to add patches to the
list of patches tied to each proposal until it is considered ready by having
its first vote added (usually from the proposer).

Suggestion 8) A vote means that the proposal was confirmed to work when
backported and that it is believed by the proposer to be of enough quality
and ready for an stable branch, this usually means that a proposal will be
usually proposed first as a work in progress with no votes and only voted
upon once it has passed initial QA and is ready for peer review.

Suggestion 9) A proposal that is marked as rejected by his own proposer
is looking for an alternative solution to the problem presented and unless
you strongly feel otherwise shouldn't be voted into.

Additionally, I think it is important to mention that votes should all be done
based on technical merit of the proposals and regardless of who is the
proposer of what everyone personally thinks about him, because the procedure
of collecting 2 votes was designed to ensure that (considering we have 5
regular committers) enough people looked at the proposals so that they are
tested, of high quality and free of regressions.

there should be no need to lobby for votes or ask for them as favours that
will be paid for later.  for now 2 votes are needed (1 of them usually from
the proposer) so that the patch can be committed and that might change with
time as more regular committers are added but taking "votes" as if they will
be some sort of political expression defeats the objective which was just
to ensure peer review is done and tracked for the greater good.

Carlo

(*) http://www.bikeshed.com/