>>> On 9/16/2008 at 3:39 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > 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". >
Was any of this necessary? We are talking about STATUS file etiquette in this email thread because some of us felt that it was an issue that needed to be addressed and clarified. Nobody was trying to point fingers so I am sorry if you felt that the finger was being pointed at you. >> 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 > The only decision that was made on IRC was to bring the summarized discussion to the mailing list for a broader discussion in accordance with what our wiki says. I'm not sure what your point is here. >> 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. > Bring up the issue on the mailing list rather than just delete votes. I may still be OK and vote +1 on the proposal and can indicate that on the mailing list without having to reenter my +1 in the STATUS file. Yes, changes to a proposal need to be re-reviewed, but making the assumption that a re-review will result in a vote change is not your call. >> 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. > I strongly disagree. If there is no technical justification for rejecting a backport proposal, then the voter is free to provide such a comment or bring it to the mailing list but can not veto the proposal. Backport proposals are not about personal preference as to how a patch was implemented. It is about technical merit, most importantly does the patch solve the problem. If someone does not like the patch, then they are free to bring forward a new patch for a vote. But unless they are willing to offer up a new patch that adequately resolves the issue, a -1 vote can not be cast without technical justification. The last thing this project needs more of are disagreements over personal preference. > 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" > Agreed. >> 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. > I am OK with simply moving the short description of each accepted backport into the changes area of the STATUS file. However after having been the release manager for two releases of the 3.1.x series, I found the auto generated ChangeLog to be completely worthless. The auto generated ChangeLog contains every change ever made to the Ganglia branch including change comments to the STATUS file itself. Weeding through the ChangeLog to find any relevant or valuable information is more work for the user than it would have been for all of us to manually update the CHANGES file after each backport. >> 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. > I have debated this one myself and even suggested to the Apache httpd project several times while I was working on the LDAP authentication with basically no one else to review my backport proposals. In the end my request to switch to lazy consensus for the httpd STATUS file was rejected by the Apache project. I still go back and forth on this one but I am leaning slightly more towards how the Apache httpd project does things. > 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 (*) > I agree, discussion about a backport proposal should be done on the mailing list. However discussions and comments are not the same thing. Comments are appropriate for the STATUS file so that someone that is reviewing backports can quickly get an idea of the current state of a proposal without having to resort to searching the mailing list. > 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). > -1, the STATUS is to reflect the current state of the release, not a place to track a work in progress. Backport proposals should only be entered into the STATUS file when they are deemed ready by the author to be ready for review and backported. The SVN trunk is for works in progress. If we want to create a new STATUS file in the trunk repository to track works in progress, then I am OK with that. But a work in progress does not belong in a stable branch STATUS file. > 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. > -1, same reason as above. A vote means that the voter has reviewed the backport proposal and believes that original author of the proposal has produced a patch that should be included in a stable branch. The backport process (RTC) is a code review process, not a QA process. > 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. > -1, same reason as suggestion #7. The STATUS file for a stable branch is suppose to reflect the current state of the branch. It is not meant to be a tracking mechanism for works in progress. That is what trunk is for. A backport proposal is only introduced in to the STATUS file of the stable branch when the original author believes that the patch is ready to be backported. In other words, if the original author can not vote for his own proposal, then why introduce it in the first place? It should remain in trunk until it is ready. > 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. > Agreed. > 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. > Agreed. I don't believe that this has ever been an issue. Brad ------------------------------------------------------------------------- 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
