On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote: > On Monday 20 July 2015 15:45:14 Robert Munteanu wrote: > > Hi, > > hi Robert, > > > It's unclear to me how to handle a release vote when the artifacts > > are > > changed during the vote. E.g. > > > > - start release on 2015-04-01 > > - a problem is discovered on 2015-04-02 > > - the problem is fixed on 2015-04-03 > > > > Is it OK to continue with the vote or do we mandate that the vote > > is > > cancelled? > > we really should cancel and start over. > > > If we decide it's OK to continue with the vote we also need to > > decide > > what to do with: > > > > - +1 votes on the previous artifacts ( probably ignore ) > > - -1 votes on the previous artifacts ( probably keep as vetos > > unless > > the voter withdraws/recasts the vote ) > > - the duration of the vote ( probably restart the 72 hours count ) > > all your points +1, but I prefer to cancel (though I didn't asked for > last > week).
Ack, whatever the outcome of this discussion is should not affect votes in progress. > > > I don't have a very strong opinion about this, but I would be less > > confused if releases were immutable :-) and any change of the > > artifacts > > under vote would mean cancelling the vote and starting a new one. > > But > > I'm happy to do what works for everyone, given what we have clear > > rules > > for it. > > +1 > > And using a dedicated repo per artifact means less work if only one > of a bunch > fails. I actually think for 'Scripting releases' vote started by Radu this was the right way to approach it. There are 4 artifacts that were changed to support a certain use case, and they are linked together with dependencies. If Radu would've staged 4 linked releases it would mean 4 votes with at least a 4x72 hours wait. With a single aggregate release we would ideally get a single 72h wait and in the worst realistic scenario a 2x72h wait due to a vote being cancelled and a second vote being staged to address the objections brought up when the first release was staged. > One more point: versions - reuse or increase? > Although versions are cheap for us, it confuses our users when > versions are > "missing". It's even more confusing that AEM 6.1 uses Sling i18n > 2.4.0 which > was _not_ released. So I'm for reusing here. +1 for reusing versions on cancelled votes. Robert
