From: Jesse B. <ha...@gm...> - 2008-09-17 00:21:29
|
On Tue, Sep 16, 2008 at 05:39, Carlo Marcelo Arenas Belon <ca...@sa...> 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. Actually, no. It stemmed more from a confusion on my part as to how proper way of doing things. "Etiquette" isn't the right word, perhaps "procedure" is better (I couldn't think of it yesterday). >> 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 No decisions were made, as I pointed out. And you'll note that this issue specifically was brought on the wider list *because* there were only three people involved. >> 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 Yep. I'm aware of that. I actually still prefer multiple lines for two reasons: 1) it makes it more obvious as to the number of votes have been cast, as well as the relative number of +1, +0, -1. 2) It makes the diffs cleaner when looking to see what votes were added/changed. However, this is such a minor thing, that it isn't worth arguing over. I suggested single lines since that seems to be what other people prefer. >> 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) I agree that new patches require new votes, but there needs to be more communication when this happens. Deleteing the votes and comments removes that information about previous patches, and potentially why it was rejected (or not) in the first place. This information is useful, and should be preserved somehow. Perhaps we could do something like this (all revisions and patch numbers are 100% bogus) * gmond: recover from interface reconfiguration gracefully http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=38 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=1478 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=1632 228 -1: carenas 229 carenas: not a fix but a workaround to the problem > > 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. A fair point. But if there are objections to the backport patch, this may mean that the upstream patch to trunk should be reviewed and possibly amended. > 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". >> 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. The purpose of this suggestion is to keep a human readable history of the votes. It can be extracted from the SVN commit logs, but having it in one (or two) places is a much easier thing to reference. There's a balance between duplication and ease of use. > 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. The current standard is 3 votes, and I think it best to keep it that way to force more eyes on the code. > Suggestion 6) No discussion should be done in the STATUS file, if there is Agreed, but a short comment as to why a +0 or -1 vote was cast is perfectly reasonable. > 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). This doesn't make sense. A proposal with no votes may simply have not been reviewed. This is independent of its merits. It is entirely possible that the first vote will be a "-1". > 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 I think that you mean "a +1 vote means that..." here. A vote can be +1, +0, or -1, and those mean different things in each case. > 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. If it's been rejected by the proposer, why bother with putting it into STATUS at all? It would be better discussed on the mailing list, where it will get much more coverage and discussion. > 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/ > -- Jesse Becker GPG Fingerprint -- BD00 7AA4 4483 AFCC 82D0 2720 0083 0931 9A2B 06A2 |