[Opendnssec-develop] OpenDNSSEC 1.4.0a2

Wed May 30 10:52:30 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/30/2012 12:37 PM, Sara Dickinson wrote:
> 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?

To my understanding, from 1.4.0 we want to have release candidates for
every release, even patches.

It is true that not all steps require the same actions, like for the
example you mentioned: a new wiki version is created only on major
versions, but the manual pages, README and NEWS files, etc. will need
updates for all versions.

> 
>> 
>>> 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.

Yes, that makes sense.

> 
> 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?

The first release process I posted was a copy of our release process
documentation, and edited it to make it suitable for OpenDNSSEC. I
think your copy is also comparable.

"Iterate around these steps": If in the release check list something
does not satisfy, and this results in code changes, we should jump
back to step 3.

We also have guidelines if we have to deal with a critical security
vulnerability (we issue a CERT ID and don't do rc's).

Overall, this copied version looks good to me.

Best regards,
  Matthijs

> 
> 
> _______________________________________________ Opendnssec-develop
> mailing list Opendnssec-develop at lists.opendnssec.org 
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPxfvoAAoJEA8yVCPsQCW52+4H/3ADQATzh1jlcnG80NHOyVR9
/j7KmcQT4b2XrNZaomJstIUgW1wXD25eX0rKsEUupJKVvs+spkRP3wvYZ2+hggrX
S+EPZpQYSALfUXqxigCm99qFB0fslvHZaVA0JCuLUD2IBpCJc8shiNB/Hdvwj4FJ
TPFcpgqGk06Z/RXj3tkNUfp/q2IZVX4+hde2kihvtwEDKC/P5uqaYMPEmGOfU7h6
EaVUGrLRx3Ig01Vs04ZHH/i8+rVsWHaI9tqk2c4FPZ7RhU1EVEaLgRFLKci+UUTH
M7bNUPySHWOR3yblVli3jNBXNKhnZOyWugcN+hU7+PwjjLLzDf8h1H+QaAOueBg=
=OBwC
-----END PGP SIGNATURE-----