Menu
▾
▴
Re: [Ganglia-developers] STATUS file etiquette (ignore previousemail please)
|
From: Brad N. <bni...@no...> - 2008-09-17 14:46:15
|
>>> On 9/16/2008 at 6:50 PM, in message <dbd...@ma...>, "Jesse Becker" <ha...@gm...> wrote: >>> 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) > > I'm not sure I like any of those options. How about if we use a modification of your first suggestion. 1. Only the original author of a proposal can change the proposal including the text and included patches. All others can only add, change or remove their respective votes or comments only. 2. If somebody votes -1 on a proposal, they put their name on the -1 line and then also add a comment with their ID next to it. Nothing different here than how we have already been working. 3. One modification to the above statement. If something needs to be added, changed or removed from the proposal including text and/or patches and bugzilla references, these notations are part of the voter's comments. The voter does not change the original proposal. The voter may also notify the devel email list of the -1 vote or any other comment or issue. 4. It is then the responsibility of the original author of the proposal to remedy the situation and add a comment indicating that the issue has been resolved. The original author can not change or remove any other's comments. All comments must remain. They may also respond to the devel mailing list that the issue has been resolved. 5. It is then the responsibility of the -1 voter (and others) to re-review the proposal and modifications to the proposal. At this point the -1 voter can either change their vote or add another comment and/or respond to the mailing list. Example: bnicholes makes a proposal to which hawson votes -1 and adds comments * 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: bnicholes -1: hawson hawson: doesn't actually work due to changes in r150. Next: bnicholes ammends the proposal by following hawson's comments in this case, adds a comment and responds to the mailing list * 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 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=200 +1: bnicholes -1: hawson hawson: doesn't actually work due to changes in r150. bnicholes: fixed the issue by adding foo-patch in r200 Finally: hawson re-reviews the proposal and ammendment, accepts the proposal and changes his vote. He may optionally add a comment and/or respond to the devel mailing list. * 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 http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=200 +1: bnicholes, hawson -1: hawson: doesn't actually work due to changes in r150. bnicholes: fixed the issue by adding foo-patch in r200 hawson: actually works. I'm changing my vote. The voting history or basically what happened during the proposal review is all captured in a series of brief comments in the STATUS file. The original author may also decide to include a link to an email thread where a more detailed discussion is or has taken place. In this process nobody messes with anybody else's votes and the original author of the proposal remains in control of the proposal. Brad |