Crud... Gmail sent the last email before I was done. (PEBKAC, really) Please ignore the previous email, and read this one instead.
On Tue, Sep 16, 2008 at 05:39, 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. 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. Consensus seems to be to use single lines, so I suggested it. I actually 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. >> 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. At the very least, a note to -devel that a new patch is present and the issue in question needs a revote. Furthermore deleting the votes and comments removes 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: report CPU color http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=12345 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=100 -1: hawson hawson: doesn't actually work due to changes in r150. http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=200 +1: hawson: actually works This is a bit cumbersome, but does have the advantage of keeping a timeline of sorts, as well as comments and vote history. Other things to possibly do would be have a date stamp of some sort: * gmond: report CPU color (proposed 2008-06-01) http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=12345 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=100 -1: hawson (2008-07-01) hawson: doesn't actually work due to changes in r150. http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=200 +1: hawson: actually works (2008-08-01) Or perhaps starting with: * gmond: report CPU color (proposed 2008-06-01) http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=12345 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=100 -1: hawson hawson: doesn't actually work due to changes in r150. and once a new patch is out, clearing votes and comments but adding a note that a revote is needed: * gmond: report CPU color (proposed 2008-06-01) http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=12345 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=100 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=200 (REVOTE NEEDED) > 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. Recall that commits to trunk don't require initial review, and may need to be reworked. This discussion is better done on the mailing lists, of course. >> 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. Votes take up to three lines. Comments have to go somewhere. It doesn't matter where, so long as it is obvious which stanza they apply to. >> 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 those log entries are almost always very sparse. For example, the bugzilla IDs and patch numbers are present in the STATUS file. By contrast, of the 1200+ commits only about 14 log entries reference a bugzilla ID, whereas every entry in the STATUS file has at least one revision number, and frequently a bugzilla ID. > 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 I don't think anyone is proposing otherwise. Code is code, regardless of who wrote it. -- Jesse Becker GPG Fingerprint -- BD00 7AA4 4483 AFCC 82D0 2720 0083 0931 9A2B 06A2 ------------------------------------------------------------------------- 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
