Open Stack

Excerpts from Thierry Carrez's message of 2015-06-19 10:01:46 +0200:
> Tony Breeds wrote:
> > The first thing is using the review to "vote" on meeting times.
> > - I'm not certain this is the best workflow but it's something worth palying
> >   with.  The key is identifying that a review is a suggestion and then
> >   identifying when that suggestion becomes golden are the key things.  So
> >   perhaps if you're looking for votes on a review -W it?  Or add a comment  like:
> >   This a a vote if there are no -1's after $datetime please merge then?
> 
> I think the irc-meetings review should not be used to decide on a
> meeting time. Same way you don't post multiple implementations of a
> feature and "vote" for the best one. You shouldn't propose something you
> don't have the intention to see merged, otherwise it's a waste of
> reviewers time.

Yes, doodles are much better for that.

> > Knowning that a meeting change is *correct* / endorsed.
> > - When a Change comes in I do verify that the new time seems to match the
> >   project wiki / documentation I can easily find.  However it's possible, as an outsider to your project, I may miss sometime and approve a "bad" change.  It isn't great for the calendar to list the wrong meetiung information.  I have 2 suggestions:
> >   1) I "require" the PTL to +1 the meeting change ; or
> >   2) The commit message contains a like to some public log that indicates the
> >      change has been discussed. (say an IRC log or mailing list archive)
> >   These 2 options aren't exclusive.  We could of course just accept mistakes
> >   will be made and handle reverts quickly but I don't really like that.
> 
> I think it's fair to request that the meeting is proposed by the group
> lead, *or* that the commit message points to reference information that
> shows that the team lead is fine with it, *or* has the lead +1 on it.

As a reviewer, I would prefer that the lead submit the patch or +1 it to
avoid any ambiguity with my interpretation of meeting logs.

Doug