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/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
