Updating a release repository during a vote

[Robert Munteanu <ro...@apache.org>]

Hi,

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?

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 )

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.

Cheers,

Robert

Re: Updating a release repository during a vote

[Julian Sedding <js...@gmail.com>]

+1 for cancelling and starting a new vote

Regards
Julian

On Mon, Jul 20, 2015 at 2:45 PM, Robert Munteanu <ro...@apache.org> wrote:
> Hi,
>
> 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?
>
> 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 )
>
> 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.
>
> Cheers,
>
> Robert

Re: Updating a release repository during a vote

[Julian Sedding <js...@gmail.com>]

> 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.

IMHO this is actually a point against re-using version. If the version
2.4.0 had been re-used, you would not even know that there is a broken
bundle in AEM 6.1.

Regards
Julian

On Mon, Jul 20, 2015 at 3:12 PM, Oliver Lietz <ap...@oliverlietz.de> 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).
>
>> 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.
>
> 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.
>
> Regards,
> O.
>
>> Cheers,
>>
>> Robert
>

Re: Updating a release repository during a vote

[Daniel Klco <da...@gmail.com>]

+1 for building all releases.

Im not sure decoupling makes the situation better. Let's say you staged an
api and implementation release. What happens if the vote passed for the api
and failed for the implementation? It's the same result, if you have
dependencies they need to either be bundled or voted on sequentially.
Bundling seems better as  most of the time, if any part fails you would
want to cancel the whole thing.
On Jul 20, 2015 9:43 AM, "Oliver Lietz" <ap...@oliverlietz.de> wrote:

> On Monday 20 July 2015 16:25:14 Robert Munteanu wrote:
> > On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote:
> [...]
> > > 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.
>
> _n_ artifacts doesn't mean necessarily _n_ x 72+ hours. The votes can run
> in
> parallel and the additional effort for voters is minimal. We should build
> each
> artifact from tag either way and not just check sums and signatures.
>
> O.
>
> > > 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
>
>
>
>

Re: Updating a release repository during a vote

[Oliver Lietz <ap...@oliverlietz.de>]

On Monday 20 July 2015 16:25:14 Robert Munteanu wrote:
> On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote:
[...]
> > 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.

_n_ artifacts doesn't mean necessarily _n_ x 72+ hours. The votes can run in 
parallel and the additional effort for voters is minimal. We should build each 
artifact from tag either way and not just check sums and signatures.

O.

> > 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

Re: Updating a release repository during a vote

[Bertrand Delacretaz <bd...@apache.org>]

On Thu, Jul 30, 2015 at 1:05 PM, Robert Munteanu <ro...@apache.org> wrote:
>... I've updated the release management page....

Thanks! Your changes look good to me.
-Bertrand

Re: Updating a release repository during a vote

[Robert Munteanu <ro...@apache.org>]

On Mon, 2015-07-27 at 14:43 +0200, Bertrand Delacretaz wrote:
> Hi,
> 
> On Mon, Jul 20, 2015 at 3:25 PM, Robert Munteanu <ro...@apache.org> 
> wrote:
> > On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote:
> > > ... 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...
> 
> I am strongly against reusing version numbers when artifacts change.
> 
> As soon as one creates a binary people can copy it around, there's no
> way to know if that happens or not.
> 
> Having two versions of an artifact with the same version numbers can
> cause major confusion. Non-consecutive version numbers are not a
> problem.

Thanks to all for the discussion. I've updated the release management
page with the following text:

Index: release-management.mdtext
===================================================================
--- release-management.mdtext   (revision 1693407)
+++ release-management.mdtext   (working copy)
@@ -159,7 +159,7 @@
  
 Be sure to include all votes in the list and indicate which votes were
binding. Consider \-1 votes very carefully. While there is te
chnically no veto on release votes, there may be reasons for people to
vote \-1. So sometimes it may be better to cancel a release wh
en someone, especially a member of the PMC, votes \-1.

-If the vote is unsuccessful, you need to fix the issues and restart
the process - see *Canceling the Release*.
+If the vote is unsuccessful, you need to fix the issues and restart
the process - see *Canceling the Release*. Note that any changes
 to the artifacts under vote require a restart of the process, no
matter how trivial. When restarting a vote version numbers must not
 be reused, since binaries might have already been copied around.
  
 If the vote is successful, you need to promote and distribute the
release - see *Promoting the Release*.

Thanks,

Robert

Re: Updating a release repository during a vote

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Jul 20, 2015 at 3:25 PM, Robert Munteanu <ro...@apache.org> wrote:
> On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote:
>>... 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...

I am strongly against reusing version numbers when artifacts change.

As soon as one creates a binary people can copy it around, there's no
way to know if that happens or not.

Having two versions of an artifact with the same version numbers can
cause major confusion. Non-consecutive version numbers are not a
problem.

-Bertrand

Re: Updating a release repository during a vote

[Robert Munteanu <ro...@apache.org>]

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

Re: Updating a release repository during a vote

[Oliver Lietz <ap...@oliverlietz.de>]

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).

> 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.

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.

Regards,
O.

> Cheers,
> 
> Robert