[Opendnssec-develop] OpenDNSSEC 1.4.0a2

[Matthijs Mekking]

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

On 05/29/2012 01:07 PM, Sara Dickinson wrote:
> Hi,
> 
> My thoughts would be that since producing tarballs isn't a great
> overhead then the benefit of making is easier for users to test the
> alpha makes it worth doing?

I agree.

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

At labs, we have two developers do the code review before doing the
release, two others than the main developer. Usually it saves a lot of
work if you track the commit messages too.

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

> - Given the above it should be clear exactly who does what. We
> could define a "Release Manager" role.

Yes.

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

> - Step 6. Seems like it would be better if a single person did all
> the announce updates - seems to make sense that this is the Project
> Manager?

Seems logical to me.

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


Best regards,
  Matthijs

> I can take a pass at updating the process after some feedback on
> the above.....
> 
> One more thought on the Release Engineering process defined in step
> 5 - could steps 4,5 and 6 of this be automated in a Jenkins job
> that is run manually?
> 
> Sara.
> 
> On 29 May 2012, at 08:38, Rickard Bellgrim wrote:
> 
>> On Tue, May 29, 2012 at 9:13 AM, Jakob Schlyter <jakob at kirei.se>
>> wrote:
>>> http://www.opendnssec.org/files/source/testing/opendnssec-1.4.0a2.tar.gz
>>>
>>>
>>> 
sorry for the delay, kind of missed we did tar-balls of alphas.
>> 
>> No problem. I now checked the release process and could not find
>> any clear distinction between the alpha releases and the final
>> releases w.r.t tarballs. Perhaps we need to clarify that?
>> 
>> // Rickard _______________________________________________ 
>> Opendnssec-develop mailing list 
>> Opendnssec-develop at lists.opendnssec.org 
>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 
> _______________________________________________ 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/

iQEcBAEBAgAGBQJPxdK6AAoJEA8yVCPsQCW5qHYH/RNXmRqKNaExuAk/DXHJwWQx
MlRZ8thte7Ag+6vdlo+s7ntuCD8yIH0AtC+86CVyFX9OSDb4tAHq1x1AsnG8kyGL
lCgMKHGYzm3u871ApTseCNt1o7vSD372Q4nRu056ZtsYK3zpPATNL74maeh0gTfT
4okxbu8CWMkb37+2ftGxjnRAU011ey9LwcRZ+hqA53mmr6osBx5GOnBuhNct+MyW
I4eSVETdPbBh1JcdzoveHhjJt4YZZpIhjb+e6ddTbkKywgMTjOGmXouMfVfkFKzi
1A/WT7UncGKGq4+aIK0WivP9jdGesrnKCYBCkbgCLfxwZ51c8dKollqF2QWXjZc=
=vF/i
-----END PGP SIGNATURE-----