[PROPOSAL] Release process management changes in wiki
Sander W G van der Waal
I have updated the wiki page on release management [1]
to includde proposed changes to the process. In summary,
I propose to implement a cycle of four two-weeks iterations
which includes a more explicit testing period than my previous
proposal and one binary release every eight weeks.
I would appreciate it if you could read the proposal and
let me know on the list what you think.
Sander
[1] http://code.google.com/p/simal/wiki/ReleaseManagement
OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
Ross Gardler
> Dear all,
>
> I have updated the wiki page on release management [1]
> to includde proposed changes to the process. In summary,
> I propose to implement a cycle of four two-weeks iterations
> which includes a more explicit testing period than my previous
> proposal and one binary release every eight weeks.
>
> I would appreciate it if you could read the proposal and
> let me know on the list what you think.
I wonder why there is no soft release of the release candidate in week
6. I appreciate that we need people to test the binary release and we
should require committers to do so, but I think it would be a good idea
to provide a running instance of the release candidate on
registry.oss-watch.org for casual testers.
We could also run a series of automated user acceptance tests against
this version as well.
------
I'm a little unclear to the purpose of the code freeze (despite my being
a part of the discussions which led to this proposal). Normally a code
freeze would mean that no commits are allowed to the version control
system, other than essential bug fixes that are voted for before
inclusion, i.e. under review then commit. The code freeze is a perioud
of intense testing with no development. The idea of giving advance
warning is to allow people to get their required features into the code
before we start testing the release.
However, in this proposal the code freeze appears to be placed and
lifted within a few days. What actually happens in this code freeze? The
proposed process says "At the end of every third iteration there will be
a code freeze to allow the release manager to create a candidate binary
release and create a release branch for it" If we are doing the release
from a branch then why the code freeze? It takes moments to create a
branch for creation an maintenance of the release, yet all the testing
is done outside of the code freeze.
Unless I am missing something about this release iteration I would
suggest it makes more sense to not have an explicit code freeze period.
Instead to do the following:
Week 5 (end of) - Soft release
Week 6 (start of) - create release branch
The warnings about "code freeze" in the communications would become
notifications of the imminent release branch.
Release branches will not accept new features, but will accept bug
fixes. When the community is large enough we will probably make the
release branches review-then-commit but at present I suspect this will
hold up the release cycle since we don't have enough developers to do
reviews.
-----
I would suggest that the soft releases should include code auditing and
issue verification. Both of these are essential maintenance tasks and
they should really be carried out continuously throughout every cycle.
To allow smooth flowing of earlier iterations we probably want to relax
the rules a little (i.e. no critical issues from code auditing rather
than no warnings required by the binary release).
-----
Looking further forward I would like to see a second test server which
continually runs SVN head. The "release" to this server will require
nothing more than a successful CI build.
I'm not suggesting we include this in your proposed release cycle just
yet, I'm just flagging it as a desire.
Ross
>
> Sander
>
> [1] http://code.google.com/p/simal/wiki/ReleaseManagement
>
> OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk
>
> --
>
> You received this message because you are subscribed to the Google Groups "Simal contributors" group.
> To post to this group, send an email to simal-con...@googlegroups.com.
> To unsubscribe from this group, send email to simal-contribut...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/simal-contributors?hl=en-GB.
>
>
Sander W G van der Waal
I agree that we should update the demo server with the rc and it
is mentioned as part of the process of creating the rc.
>
> We could also run a series of automated user acceptance tests
> against this version as well.
>
> ------
>
> I'm a little unclear to the purpose of the code freeze
> (despite my being a part of the discussions which led to this
> proposal). Normally a code freeze would mean that no commits
> are allowed to the version control system, other than
> essential bug fixes that are voted for before inclusion, i.e.
> under review then commit. The code freeze is a perioud of
> intense testing with no development. The idea of giving
> advance warning is to allow people to get their required
> features into the code before we start testing the release.
>
> However, in this proposal the code freeze appears to be
> placed and lifted within a few days. What actually happens in
> this code freeze? The proposed process says "At the end of
> every third iteration there will be a code freeze to allow
> the release manager to create a candidate binary release and
> create a release branch for it" If we are doing the release
> from a branch then why the code freeze? It takes moments to
> create a branch for creation an maintenance of the release,
> yet all the testing is done outside of the code freeze.
The 'code freeze' period in this proposal is indeed nothing more
than creating the release branch, so I understand why it's
confusing.
>
> Unless I am missing something about this release iteration I
> would suggest it makes more sense to not have an explicit
> code freeze period.
> Instead to do the following:
>
> Week 5 (end of) - Soft release
> Week 6 (start of) - create release branch
I don't really understand this. What happens during this 'soft
release'? Why are these two separate steps? I would prefer to
have the binary rc on the demo server, so would think these are
done in one step (this is how I tried to describe the process
of creating the rc). Why did you move the soft release to one
week earlier? It interferes a bit with the biweekly iterations.
>
> The warnings about "code freeze" in the communications would
> become notifications of the imminent release branch.
Yes, this keeps the main intention of how I understood these
notiifcations: make sure you have checked in everything that
you want in the next release.
>
> I would suggest that the soft releases should include code
> auditing and issue verification. Both of these are essential
> maintenance tasks and they should really be carried out
> continuously throughout every cycle.
Agreed, I'll add that to the doc.
>
> To allow smooth flowing of earlier iterations we probably
> want to relax the rules a little (i.e. no critical issues
> from code auditing rather than no warnings required by the
> binary release).
Yes, I'll add that as well. This will be 'no cricital issues'
for the soft releases in the 1st and 2nd iterations and 'no
warnings' for the 3rd iteration when the rc is created, as
we don't want want to fix that on the release branch.
Sander
Ross Gardler
>
>
>> -----Original Message-----
>> [mailto:simal-con...@googlegroups.com] On Behalf Of Ross Gardler
>> Sent: 22 December 2009 16:25
...
>> On 21/12/2009 12:36, Sander W G van der Waal wrote:
>>> Dear all,
>>>
...
> The 'code freeze' period in this proposal is indeed nothing more
> than creating the release branch, so I understand why it's
> confusing.
>
>>
>> Unless I am missing something about this release iteration I
>> would suggest it makes more sense to not have an explicit
>> code freeze period.
>> Instead to do the following:
>>
>> Week 5 (end of) - Soft release
>> Week 6 (start of) - create release branch
>
> I don't really understand this. What happens during this 'soft
> release'?
I'm using the term as defined in your doc, i.e. an update of
registry.oss-watch.ac.uk
> Why are these two separate steps? I would prefer to
> have the binary rc on the demo server, so would think these are
> done in one step (this is how I tried to describe the process
> of creating the rc).
Because your process defines a soft release and a binary release as two
separate things. The binary release process starts at the beginning of
every 4th iteration. I was simply trying to keep to the process already
defined.
However, thinking about it you are right, The branch should be created
when the final soft release is made otherwise we would have a weekend of
commits in the binary release that are not in the soft release.
> Why did you move the soft release to one
> week earlier? It interferes a bit with the biweekly iterations.
That's an error in my reading of your diagram (which by the way is a
broken link right now, not sure if that's a transient thing or not as
I'm on a poor net connection right now).
>> To allow smooth flowing of earlier iterations we probably
>> want to relax the rules a little (i.e. no critical issues
>> from code auditing rather than no warnings required by the
>> binary release).
>
> Yes, I'll add that as well. This will be 'no cricital issues'
> for the soft releases in the 1st and 2nd iterations and 'no
> warnings' for the 3rd iteration when the rc is created, as
> we don't want want to fix that on the release branch.
>
+1
Ross