flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: Mustella tests failing and release candidates
Date Sun, 13 Oct 2013 08:27:56 GMT
Justin,

I'm lost. You tell us the current release workflow is too much work
and to fragile. We suggest way to reduce the workload and make the
process more robust... And you come back telling us the current
workflow is the best way.

What are we missing? What are you asking of us?

I sure hope you don't expect us to vote +1 (binding) within an hour of
calling the VOTE, no matter the current condition of the codebase ;-)

Anyway, here are my suggestions:

1) a few day before cutting the release branch: alert everyone that if
they want their contributions in the release, they should push them to
'develop'
2) once all contributions have landed, cut the release branch; switch
all Jenkins jobs and Mustella runs to 'release'; leave the release
branch alone for 2 days so Mustella can be run in all configs. This is
an import step in making sure the 'release' code is in good shape
3) if and when the all lights are green (no failing tests, all builds
correct), cut RC 1 and start the VOTE, preferably around a Wednesday -
that way there are a couple of work days and a weekend ahead, which
would allow both the worktimers and the weekenders to participate
4) after about 5 days (see 4) tally the votes. If needed fix stuff on
'release', rinse and repeat from 2.

I really think this will cut down significantly on the work of the
release manager, as there will be a lot less RCs. It will take more
time, sure, but I don't think that is a bad thing in this case.

EdB



On Sun, Oct 13, 2013 at 10:03 AM, Justin Mclean
<justin@classsoftware.com> wrote:
> Hi,
>
>> How would this help with running Mustella tests on the release branch,
>> which is want Erik's point was?
>
> You don't you keep running them off develop - less effort for all involved I think that
way. Merge often and there's less issues all round.
>
> For instance what happens if after several release cycles and a final release you go
back to running tests develop and it several test are broken how do you know what checkin
it was?
>
> Justin



-- 
Ix Multimedia Software

Jan Luykenstraat 27
3521 VB Utrecht

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

Mime
View raw message