New Release Process (was Re: Release 1.2 of Tour De Flex)

[Alex Harui <ah...@adobe.com>]

Changing the subject to make sure folks not interested in TDF also pay
attention.

For folks who haven’t been following closely, there’s been discussion on
trying to find a more efficient way to do releases.  In the past we cut a
release candidate (RC) and start a vote but if issues are found, we have
to cancel the vote, do another RC, and start yet another vote.

A suggestion was made and supported by at least one board member to do
more discussion and testing before calling for a vote.  Therefore, if
critical issues are found, there isn’t the additional overhead of
canceling and restarting votes.

So below is a proposal with my comments in-line.  Feedback from everyone
is welcome.

On 10/26/14, 3:19 AM, "Harbs" <ha...@gmail.com> wrote:
>
>It seems to me that there are two types of releases: Normal releases and
>“hot fix” releases. In the case of a normal release, I think there should
>be mechanism built in to encourage people to commit fixes prior to the
>release. I’m thinking something like this:
>
>1) There would be a period of time until a release is “frozen”. 72 hours?
>Anyone working on something that should go into the release should commit
>their work to develop before that time is up.

I would call this a “last call for changes”.  I think that’s what Justin
is doing now for TDF1.2.  I would suggest that we create nightly builds
for TDF and other packages we release so the barrier to testing for folks
who don’t have the repos is lower.  They can poke at the nightly and let
us know if they see any show-stoppers.

>
>2) Once the freeze goes into effect, a branch is made for release x.xx
>for xyz

I would say that during the “last call”, if nobody speaks up with a plan
to commit stuff soon that shouldn’t be put into the release, that a
release branch is optional.  IMO, no need to create extra work for these
lower-traffic packages.

I’m guessing the reason you want to “freeze” the source is so we can
better manage what we are voting on, but IMO, we can take it on a
case-by-case basis.  If someone does have some new thing they want to add
at the last minute we can discuss whether to do it or not.  For TDF, if it
is some third-party example, I’d probably say yes.
 

>
>3) A discussion/VOTE is opened at that point and kept open until the
>release is voted through. Any issues discovered should be corrected in
>the release branch. If they are applicable to future releases, the change
>should be applied to develop as well.

I think it would be simpler to open the discussion but not a vote until
the discussion doesn’t appear to have any release blockers being
discussed.  We should probably make sure we’ve heard positive thoughts
from enough folks to be very sure the vote will succeed.

We could open the vote sooner.  Technically Justin is probably right that
votes are supposed to be on a specific artifact [1] but we already fudge
that with carry-over votes.

>
>For hot fixes, the last release branch should probably be branched and we
>should have an expedited voting process.

More than one board member has said that the 72-hour requirement is just a
guideline and not policy so yes, we can have shorter vote cycles unless we
get objections from the community.

[1] http://www.apache.org/dev/release.html#approving-a-release

Re: New Release Process (was Re: Release 1.2 of Tour De Flex)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I would say that during the “last call”, if nobody speaks up with a plan
> to commit stuff soon that shouldn’t be put into the release, that a
> release branch is optional.

It's easy enough to create a release branch, but merging back into dev and master can sometimes be painful. I'm not sure what the point is for the utilities as we have many projects in a single repository and gits inability to handle sub trees simply.

What has happen in the past (on a couple of occasions when working on a SDK release) is people have checked into the wrong branch which caused some merging issues. Also the automated test were mostly run on the develop not the release branch which also caused some issues. The simpler it is the less is likely to it is to cause issues IMO.

Given it's simplicity (and no automated tests) I can't see TDF having any issues along those lines.

>  For TDF, if it is some third-party example, I’d probably say yes.

Third party examples are external and not part of the release.

> I think it would be simpler to open the discussion but not a vote until
> the discussion doesn’t appear to have any release blockers being
> discussed.

+1 The concern I have is that this period could drag on a lot longer than the normal RC cycle and that people wont check things carefully until a vote is called.

> More than one board member has said that the 72-hour requirement is just a
> guideline

But there needs to be a good reason for it to be shorter, given we are volunteers and are scattered across the global 72 seems a reasonable amount of time someone cay check and vote on a release. [1] (last bit in expressing votes).It's rare that we get 3 votes in under 48 hours anyway.

Thanks,
Justin

1. http://www.apache.org/foundation/voting.html

Re: New Release Process (was Re: Release 1.2 of Tour De Flex)

[OmPrakash Muppirala <bi...@gmail.com>]

On Oct 26, 2014 7:57 AM, "Alex Harui" <ah...@adobe.com> wrote:
>
> Changing the subject to make sure folks not interested in TDF also pay
> attention.
>
> For folks who haven’t been following closely, there’s been discussion on
> trying to find a more efficient way to do releases.  In the past we cut a
> release candidate (RC) and start a vote but if issues are found, we have
> to cancel the vote, do another RC, and start yet another vote.
>
> A suggestion was made and supported by at least one board member to do
> more discussion and testing before calling for a vote.  Therefore, if
> critical issues are found, there isn’t the additional overhead of
> canceling and restarting votes.
>
> So below is a proposal with my comments in-line.  Feedback from everyone
> is welcome.
>
> On 10/26/14, 3:19 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >It seems to me that there are two types of releases: Normal releases and
> >“hot fix” releases. In the case of a normal release, I think there should
> >be mechanism built in to encourage people to commit fixes prior to the
> >release. I’m thinking something like this:
> >
> >1) There would be a period of time until a release is “frozen”. 72 hours?
> >Anyone working on something that should go into the release should commit
> >their work to develop before that time is up.
>
> I would call this a “last call for changes”.  I think that’s what Justin
> is doing now for TDF1.2.  I would suggest that we create nightly builds
> for TDF and other packages we release so the barrier to testing for folks
> who don’t have the repos is lower.  They can poke at the nightly and let
> us know if they see any show-stoppers.

I just want to add that if someone is planning on making time to test an
RC, they can announce it in the discuss thread so that they are given the
time to do so.  Of course, it is up to the release manager to make the call
about waiting our not, especially if 72 hours to pass by and enough votes
for a release are already available.

That's,
Om

>
> >
> >2) Once the freeze goes into effect, a branch is made for release x.xx
> >for xyz
>
> I would say that during the “last call”, if nobody speaks up with a plan
> to commit stuff soon that shouldn’t be put into the release, that a
> release branch is optional.  IMO, no need to create extra work for these
> lower-traffic packages.
>
> I’m guessing the reason you want to “freeze” the source is so we can
> better manage what we are voting on, but IMO, we can take it on a
> case-by-case basis.  If someone does have some new thing they want to add
> at the last minute we can discuss whether to do it or not.  For TDF, if it
> is some third-party example, I’d probably say yes.
>
>
> >
> >3) A discussion/VOTE is opened at that point and kept open until the
> >release is voted through. Any issues discovered should be corrected in
> >the release branch. If they are applicable to future releases, the change
> >should be applied to develop as well.
>
> I think it would be simpler to open the discussion but not a vote until
> the discussion doesn’t appear to have any release blockers being
> discussed.  We should probably make sure we’ve heard positive thoughts
> from enough folks to be very sure the vote will succeed.
>
> We could open the vote sooner.  Technically Justin is probably right that
> votes are supposed to be on a specific artifact [1] but we already fudge
> that with carry-over votes.
>
> >
> >For hot fixes, the last release branch should probably be branched and we
> >should have an expedited voting process.
>
> More than one board member has said that the 72-hour requirement is just a
> guideline and not policy so yes, we can have shorter vote cycles unless we
> get objections from the community.
>
> [1] http://www.apache.org/dev/release.html#approving-a-release
>

Re: New Release Process (was Re: Release 1.2 of Tour De Flex)

[Erik de Bruin <er...@ixsoftware.nl>]

Here is my reply from the previous thread:


> 1) There would be a period of time until a release is “frozen”.
>
> IMO there's no need for a freeze, branching should take care of any issue.
> I don't think a freeze would of solved any issue we're run into in the past.
>

The freeze would be the cutting of the release branch. There needs to be a
grace period before that, as Harbs indicates, where a call goes out to
check in any and all changes that people want to be in the release. We are
currently in the 'grace period' for the 4.14 release, waiting for the iOS 7
skins and some other contributions.

EdB


-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl

Re: New Release Process (was Re: Release 1.2 of Tour De Flex)

[Erik de Bruin <er...@ixsoftware.nl>]

> Changing the subject to make sure folks not interested in TDF also pay
> attention.
>

I find this thread hopping very confusing. Even more so then having a
discussion in a thread with a "wrong" title :-(

EdB




-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

T. 06-51952295
I. www.ixsoftware.nl