New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

On 11/3/14, 3:30 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>I asked for feedback over a period of a week and only feedback was to
>change a title. Without a release candidate is seens to me that people are
>unwilling to check things.

Right, I understood the prior thread to be a “last call for new features”.
 Maybe in the future it should be tagged [LAST CALL].  During that phase,
we tweaked a few things like the disclaimer.

I expected the next step is that you put up a release candidate and open a
[DISCUSS] thread, but not a [VOTE] thread.  We still have it iron out the
wrinkles, but I expected that there wouldn’t be a numbering of the
candidates, just a “I have put a package on dist/dev. What do folks think
of it?”

Then we’d ask folks to try it out and after it appears that enough folks
have tried it (and yes, pleading and begging might be involved), then a
formal vote would be started.  If issues are found during the discussion
phase, you can just drop a new package over the old package.  No need to
cancel vote threads and start new ones.  If you do replace the package,
note that in the discuss thread with what changed.  Folks who’ve already
looked at the older package can then decide whether they need to look at
the new one.  Hopefully they follow commits@ more closely during the
discuss phase as well.

For TDF, because it is an “app”, if you want more feedback, it might be
reasonable to post a deployed version of TDF somewhere like your personal
folder so folks who aren’t on the PMC can more easily poke at it.  The PMC
folks have to vote on the source package, but others should be able to try
the binaries without having to download and expand the binary package.

-Alex

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

On 11/5/14, 1:32 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>I'll also point out that what is currently being looked at it identical
>to RC0 that I called a vote on a week ago, so there would be no need to
>cancel that vote and call another one.

I think the MD5s probably changed.  SWFs built at different times from the
same source have different MD5s, unfortunately.  But yes, this one took a
while because we’re working out the kinks in the new process.  Some
release was going to be subjected to that.  Plus, we now have nightly
builds of TDF thanks to Erik.

>
>There's only been one change made to the release branch which was an
>addition of a MD5 check by Alex and IMO probably should be been checked
>into develop not the release branch but not really an issue either way.

I wanted to get the MD5’s published so the approval scripts can work and
more people might test.  I reverted from develop and re-checked into the
release branch.  I’m getting set up to run the approval script now.

>
>I do see this as a bigger issue on more complex releases if we go down
>the "noRC" path, releases only require 3 +1 and more +1 than -1, in a
>discussion it can be hard to know if someone considers something a
>minor/major or blocker issues unless they state what their voting
>intention would be. Without RCs/vote threads the discussion could
>conceivably go on for a long time without any clear consensus if a vote
>should even be called or not, prolonging the voting process and costing
>more time for everyone involved.

Folks who find blockers should declare them as such in the DISCUSS thread.

-Alex

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

I'll also point out that what is currently being looked at it identical to RC0 that I called a vote on a week ago, so there would be no need to cancel that vote and call another one.

There's only been one change made to the release branch which was an addition of a MD5 check by Alex and IMO probably should be been checked into develop not the release branch but not really an issue either way.

I do see this as a bigger issue on more complex releases if we go down the "noRC" path, releases only require 3 +1 and more +1 than -1, in a discussion it can be hard to know if someone considers something a minor/major or blocker issues unless they state what their voting intention would be. Without RCs/vote threads the discussion could conceivably go on for a long time without any clear consensus if a vote should even be called or not, prolonging the voting process and costing more time for everyone involved.

Thanks,
Justin

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

> If the people who said they were looking at something have reported back,
> if all promised fixes have been committed and if all tweaks to the docs
> have been made - in other words, when the release branch has stabilised 
> the RM decides when to call the vote.

IMO That is currently the case but it's not clear that PMC members have done any of the required checks. Anyone?

Thanks,
Justin

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

>
> OK we currently have two (minor) issues which I'm unable to produce
> locally. And I have no idea if any PMC members have checked the important
> things like hashes and the like. How do we progress from here? How does the
> RM decide when it's time call a vote? So far this process has taken longer
> than the normal RC one (2 weeks and counting) and that impacts on (non full
> time) people being RM.
>

If the people who said they were looking at something have reported back,
if all promised fixes have been committed and if all tweaks to the docs
have been made - in other words, when the release branch has stabilised -
the RM decides when to call the vote. Once the vote is called, there is no
room for discussion any more, and the only reason it may be cancelled is if
a true blocking issue happens to come to light.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

OK we currently have two (minor) issues which I'm unable to produce locally. And I have no idea if any PMC members have checked the important things like hashes and the like. How do we progress from here? How does the RM decide when it's time call a vote? So far this process has taken longer than the normal RC one (2 weeks and counting) and that impacts on (non full time) people being RM.

Thanks,
Justin

RE: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

[Neil Madsen <li...@cranialinteractive.com>]

+1 to this.  

-----Original Message-----

I like this idea to have a special nightly build for releases during the
release process. It seems to me that it should simplify the process all
around.

Harbs

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

[Harbs <ha...@gmail.com>]

I like this idea to have a special nightly build for releases during the release process. It seems to me that it should simplify the process all around.

Harbs

On Nov 4, 2014, at 9:38 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

>> 
>>> I'd go (and will go) one further, and use nightlies during this phase.
>> 
>> How would that be possible given nightly are off the develop branch not a
>> release branch. Other people may check stuff into develop that we don't
>> want in the release under consideration. Also currently there are no
>> nightly of Tour De Flex and I'm not sure if we want to create a binary
>> nightly for it (given it size). May make more sense for other Flex sub
>> projects however.
>> 
> 
> That was very selective quoting ... I clearly state "the latest HEAD from
> the release branch."
> 
> It takes very little effort for the release manager to set up a copy of the
> build of the develop branch and point it to the release branch. I already
> prepared the jobs for the 4.14 release and it certainly didn't take me as
> long as it would to prepare an RC. Moreover, you have to do this only once,
> you can re-use that same build job for future releases, simply by pointing
> it to the current release branch.
> 
> EdB
> 
> 
> 
> -- 
> Ix Multimedia Software
> 
> Jan Luykenstraat 27
> 3521 VB Utrecht
> 
> T. 06-51952295
> I. www.ixsoftware.nl

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

The nightly source builds can be found here:

http://apacheflexbuild.cloudapp.net:8080/job/flex-utilities_tour-de-flex-release/lastSuccessfulBuild/artifact/TourDeFlex/TourDeFlex3/out/

The nightly 'binary' build can be viewed here (for the time being, until I
figure out a way to archive that properly):

http://apacheflexbuild.cloudapp.net:8080/job/flex-utilities_tour-de-flex-release/ws/TourDeFlex/TourDeFlex3/src/index.html

Thanks,

EdB




On Tue, Nov 4, 2014 at 10:03 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:

> Waiting on for the 'flex-sdk' job to finish so I can try the new TDF
> release build.
>
> EdB
>
>
>
> On Tue, Nov 4, 2014 at 9:18 AM, Justin Mclean <ju...@classsoftware.com>
> wrote:
>
>> Hi,
>>
>> > That is not at all what I wrote. Please read emails more carefully
>>
>> I did read it carefully you said "It takes very little effort for the
>> release manager to set up a copy of the build of the develop branch".
>>
>> Given it takes very little effort and you now say that it's not the
>> release manager reasonability could you (or someone else more familiar with
>> the current CI setup) mind setting up a CI job for Tour De Flex release
>> branch?
>>
>> Thanks,
>> Justin
>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Waiting on for the 'flex-sdk' job to finish so I can try the new TDF
release build.

EdB



On Tue, Nov 4, 2014 at 9:18 AM, Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> > That is not at all what I wrote. Please read emails more carefully
>
> I did read it carefully you said "It takes very little effort for the
> release manager to set up a copy of the build of the develop branch".
>
> Given it takes very little effort and you now say that it's not the
> release manager reasonability could you (or someone else more familiar with
> the current CI setup) mind setting up a CI job for Tour De Flex release
> branch?
>
> Thanks,
> Justin




-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

> That is not at all what I wrote. Please read emails more carefully

I did read it carefully you said "It takes very little effort for the release manager to set up a copy of the build of the develop branch". 

Given it takes very little effort and you now say that it's not the release manager reasonability could you (or someone else more familiar with the current CI setup) mind setting up a CI job for Tour De Flex release branch?

Thanks,
Justin

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

>
> > That was very selective quoting ... I clearly state "the latest HEAD from
> > the release branch."
>
> So we would need to either alter existing CI jobs and add additional ones
> every time a release branch is made?
>

That is not at all what I wrote. Please read emails more carefully ... I
refer you to the recent discussion about email etiquette and include the
relevant part from my email that you missed:

"It takes very little effort for the release manager to set up a copy of
the build of the develop branch and point it to the release branch. [...]
Moreover, you have to do this only once, you can re-use that same build job
for future releases, simply by pointing it to the current release branch."

There are several people on this list that can help anyone who needs a new
CI job, but are not familiar with Jenkins. The release manager doesn't live
in a vacuum, he can and should call upon the community to help create the
best release possible.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

> That was very selective quoting ... I clearly state "the latest HEAD from
> the release branch."

So we would need to either alter existing CI jobs and add additional ones every time a release branch is made?

> It takes very little effort for the release manager to set up a copy of the
> build of the develop branch and point it to the release branch. 

Sounds like we adding more stuff for the release manager to do not less, plus not every one is familiar with the current CI set up.

Thanks,
Justin

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

>
> > I'd go (and will go) one further, and use nightlies during this phase.
>
> How would that be possible given nightly are off the develop branch not a
> release branch. Other people may check stuff into develop that we don't
> want in the release under consideration. Also currently there are no
> nightly of Tour De Flex and I'm not sure if we want to create a binary
> nightly for it (given it size). May make more sense for other Flex sub
> projects however.
>

That was very selective quoting ... I clearly state "the latest HEAD from
the release branch."

It takes very little effort for the release manager to set up a copy of the
build of the develop branch and point it to the release branch. I already
prepared the jobs for the 4.14 release and it certainly didn't take me as
long as it would to prepare an RC. Moreover, you have to do this only once,
you can re-use that same build job for future releases, simply by pointing
it to the current release branch.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

> I'd go (and will go) one further, and use nightlies during this phase.

How would that be possible given nightly are off the develop branch not a release branch. Other people may check stuff into develop that we don't want in the release under consideration. Also currently there are no nightly of Tour De Flex and I'm not sure if we want to create a binary nightly for it (given it size). May make more sense for other Flex sub projects however.

Thanks,
Justin

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

>
> >  If issues are found during the discussion phase, you can just drop a
> new package over the old package.
>
> -1 to this as this will cause all sort of confusion to exactly what
> version an issue was in or what version people tested and this could more
> RCs rounds not less and a lot more work for the release manager.  There are
> also issues with caching so that people may think they are testing the
> latest version but are actually testing an older one. It's not a large
> amount of effort to number them as rc0, rc1 etc etc but not call a vote
> until the later rcs and there appears to be no outstanding issues.
>

I'd go (and will go) one further, and use nightlies during this phase.
These should always contain the latest HEAD from the release branch,
therefor are "state of the art." All testers download the latest nightly
before they start. I makes no sense to work on a week old version just
because the release manager didn't have time to update the RC. This is one
of the reasons we have automated builds upon every commit.

EdB



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

On 11/3/14, 11:24 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>>> For TDF, because it is an “app”, if you want more feedback, it might be
>>> reasonable to post a deployed version of TDF somewhere like your
>>>personal
>>> folder
>
>It will take an hour or so to upload a tar of the files via scp to
>people.apache.org.  Part of the reason we don't have a binary release of
>Tour De Flex as it's on the largish size. Hopefully that won't exceed any
>limits infra have placed.

What if we got the CI server to build it?  Then it wouldn’t need to be
uploaded anywhere.  Non-PMC members can poke at the nightly build and let
us know if they see anything wrong.

-Alex

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

>> For TDF, because it is an “app”, if you want more feedback, it might be
>> reasonable to post a deployed version of TDF somewhere like your personal
>> folder

It will take an hour or so to upload a tar of the files via scp to people.apache.org.  Part of the reason we don't have a binary release of Tour De Flex as it's on the largish size. Hopefully that won't exceed any limits infra have placed.

Thanks,
Justin

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

Hi,

> I expected the next step is that you put up a release candidate and open a
> [DISCUSS] thread, but not a [VOTE] thread.

Fair enough. I have opens a discuss thread but had very little response. Given we had a discussion open for over a week and no major issues have been found what do you recommend?

>  If issues are found during the discussion phase, you can just drop a new package over the old package.  

-1 to this as this will cause all sort of confusion to exactly what version an issue was in or what version people tested and this could more RCs rounds not less and a lot more work for the release manager.  There are also issues with caching so that people may think they are testing the latest version but are actually testing an older one. It's not a large amount of effort to number them as rc0, rc1 etc etc but not call a vote until the later rcs and there appears to be no outstanding issues.

> For TDF, because it is an “app”, if you want more feedback, it might be
> reasonable to post a deployed version of TDF somewhere like your personal
> folder

OK.

Thanks,
Justin

Re: New Release Process (was: [DISCUSSION] TourDeFlex 1.2 RC 0)

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

+1

Excellent summary!

EdB



On Tuesday, November 4, 2014, Alex Harui <ah...@adobe.com> wrote:

>
>
> On 11/3/14, 3:30 PM, "Justin Mclean" <justin@classsoftware.com
> <javascript:;>> wrote:
>
> >Hi,
> >
> >I asked for feedback over a period of a week and only feedback was to
> >change a title. Without a release candidate is seens to me that people are
> >unwilling to check things.
>
> Right, I understood the prior thread to be a “last call for new features”.
>  Maybe in the future it should be tagged [LAST CALL].  During that phase,
> we tweaked a few things like the disclaimer.
>
> I expected the next step is that you put up a release candidate and open a
> [DISCUSS] thread, but not a [VOTE] thread.  We still have it iron out the
> wrinkles, but I expected that there wouldn’t be a numbering of the
> candidates, just a “I have put a package on dist/dev. What do folks think
> of it?”
>
> Then we’d ask folks to try it out and after it appears that enough folks
> have tried it (and yes, pleading and begging might be involved), then a
> formal vote would be started.  If issues are found during the discussion
> phase, you can just drop a new package over the old package.  No need to
> cancel vote threads and start new ones.  If you do replace the package,
> note that in the discuss thread with what changed.  Folks who’ve already
> looked at the older package can then decide whether they need to look at
> the new one.  Hopefully they follow commits@ more closely during the
> discuss phase as well.
>
> For TDF, because it is an “app”, if you want more feedback, it might be
> reasonable to post a deployed version of TDF somewhere like your personal
> folder so folks who aren’t on the PMC can more easily poke at it.  The PMC
> folks have to vote on the source package, but others should be able to try
> the binaries without having to download and expand the binary package.
>
> -Alex
>
>

-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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