[Opendnssec-develop] OpenDNSSEC 1.4.0a2

[Sara Dickinson]

Jerry, Sion, Matthijs - thanks for the comments. 
> 
>> Other comments on the updated Release process:
>> 
>> - I would like to see the code review at the top of the list - in
>> fact it could be argued this should be part of the
>> development/pre-release process, not the release process since it
>> is the responsibility of the developers not the person doing the
>> release
> 
> The argument that the code review is at step 3 is that documentation
> updates and testing can resolve in more code changes, that need to be
> reviewed then again.
> 
> Also, the release process is not targeted at just the person doing the
> release. The steps makes sure that all actions have been taken before
> making the tarball public. So if for example Jerry is sending out a
> release candidate, he should make sure that code reviews have been
> done.

OK - I think I misunderstood. I had assumed that all the updating of the 
documentation content and developer testing was complete before the 
'Release Process' began and the process described what happened after
a team meeting had given the release go ahead (also see below) - 
purely the mechanics of a release.

So I had interpreted Step 1 as simply a sanity check and updates of the 
wiki/PDF/NEWS sections and Step 2 as simply a sanity check to ensure 
that the the specific revision used for the release passes all the tests. 


> How exactly we want to do that, I don't know. We could assign
> one developer to a piece of code (enforcer, signer, libhsm), or we
> could have a couple of developers look at the whole source (multi
> coverage).

This is something we should probably talk about in a team meeting.

> 
>> - Are any code integrity tools run regularly e.g. Coverity? It
>> seems like this should be done before a major and probably a minor
>> release after code review updates.
> 
> I like to see Coverity or something similar to be part of the release
> process.

I'll take an action to follow this up. 

> 
>> - I think it the process could clarify more between
>> minor/major/patch releases (e.g. in terms of documentation and
>> package maintenance)
> 
> I don't think any of the steps could be skipped, even not for the
> patch releases.

A minor point but IFAIK a new wiki version (i.e. moving the DOCSTRUNK 
space to DOCS) is only done on major versions. This is what the 
first sentence of Step 1 describes. Also are release candidates created for 
all versions even patches now - I didn't realise this? 

> 
>> IMHO it would also be nice to have a release criteria defined e.g.
>> no open blocker/critical bugs and all open major bugs have
>> workarounds. Any thoughts on this?
> 
> Usually there is a feature freeze. I guess there can also be a bug
> report freeze. You don't accept new bug reports if you have decided on
> a release?
> 
> I'd rather like to stick with our two week telephone conference call
> and decide on 'Can we release?'.

Absolutely - I really meant a checklist that could be used in that meeting
in addition to the team agreement. For example - 'is everyone done updating 
the documentation?' 'is everyone done with all their testing'......which is why 
I think code review should be considered here. So this part of the process 
would be the team responsibility.

I've put a slightly modified version here for review which might clear things up:

https://wiki.opendnssec.org/display/OpenDNSSEC/Copy+of+Release+Management+Process

Don't know how this compares to NLNet Labs?