From sara at sinodun.com  Tue Mar  5 16:16:14 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 5 Mar 2013 16:16:14 +0000
Subject: [Opendnssec-develop] Test platform freebsd 9 amd64 core dump
References: <CAGTFMNbUDmqu2iNxQJh1mvbm6zc0fB6kx=RoT7aPr096HdShQw@mail.gmail.com>
Message-ID: <B27B90EC-47A1-4336-A539-6AF21656D2B8@sinodun.com>

Hi All, 

We are having more problems with the strange segmentation fault seen _only_ on the 64bit FreeBSD machine. One of the enforcer tests is now persistently failing with the first core dump below and has had to be disabled and another signer test is failing intermittently with the same problem. The other 2 core dumps have also been seen intermittently on other tests or checks on this machine. All originate in _pthread_mutex_init_calloc_cb () so the belief is it a strange freebsd/pthread problem but nothing jumps out when you Google the problem. 

Does anyone have any bright ideas as to how we could workaround this? (At the moment the ax_pthread.m4 macro configures the threading library.)

Sara.

Core Dump 1:
#0  0x0000000801e923b0 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7
#1  0x0000000801e9aad5 in free () from /lib/libc.so.7
#2  0x00000008029592e5 in Botan::EGD_EntropySource::~EGD_EntropySource () from /usr/local/lib/libbotan.so.0
#3  0x0000000802a79f7f in std::for_each<__gnu_cxx::__normal_iterator<Botan::EntropySource**, std::vector<Botan::EntropySource*, std::allocator<Botan::EntropySource*> > >, Botan::del_fun<Botan::EntropySource> > () from /usr/local/lib/libbotan.so.0
#4  0x0000000802a77165 in Botan::HMAC_RNG::~HMAC_RNG () from /usr/local/lib/libbotan.so.0
#5  0x0000000802a7d295 in Botan::ANSI_X931_RNG::~ANSI_X931_RNG () from /usr/local/lib/libbotan.so.0
#6  0x0000000802a76ad1 in Botan::AutoSeeded_RNG::~AutoSeeded_RNG () from /usr/local/lib/libbotan.so.0
#7  0x0000000802174ffb in ~SoftSession (this=0x802474a00) at ../../../src/lib/SoftSession.cpp:108
#8  0x00000008021744fd in SoftHSMInternal::closeSession (this=0x8024a7f00, hSession=Variable "hSession" is not available.
) at ../../../src/lib/SoftHSMInternal.cpp:180
#9  0x000000000042898e in hsm_session_close ()
#10 0x0000000000428a5f in hsm_ctx_close ()
#11 0x000000000042b73a in hsm_destroy_context ()
#12 0x0000000000414cd0 in cmd_genkeys ()
#13 0x000000000040c40c in main ()


Core Dump 2:

> #0  0x0000000801e733b0 in _pthread_mutex_init_calloc_cb () from
> /lib/libc.so.7
> #1  0x0000000801e7bad5 in free () from /lib/libc.so.7
> #2  0x00000008008d95f5 in xmlHashFree () from /usr/local/lib/libxml2.so.5
> #3  0x0000000800901844 in xmlXPathRegisteredFuncsCleanup () from
> /usr/local/lib/libxml2.so.5
> #4  0x000000080090187a in xmlXPathFreeContext () from
> /usr/local/lib/libxml2.so.5
> #5  0x00000000004082c3 in read_zonelist_filename ()
> #6  0x0000000000405ef7 in do_communication ()
> #7  0x0000000000404e3c in server_main ()
> #8  0x0000000000409ebb in main ()


Core Dump 3:
> 
> #0  0x0000000801e36400 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7
> [New Thread 802407400 (LWP 100105/<unknown>)]
> [New LWP 100113]
> (gdb) bt
> #0  0x0000000801e36400 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7
> #1  0x0000000801e3ead5 in free () from /lib/libc.so.7
> #2  0x000000080130307e in sqlite3HashClear () from
> /usr/local/lib/libsqlite3.so.8
> #3  0x000000080130ec60 in sqlite3SchemaClear () from
> /usr/local/lib/libsqlite3.so.8
> #4  0x0000000801310c25 in sqlite3ResetInternalSchema () from
> /usr/local/lib/libsqlite3.so.8
> #5  0x0000000801337522 in sqlite3_close () from /usr/local/lib/libsqlite3.so.8
> #6  0x000000080211e38d in ~SoftDatabase (this=0x80257d160) at
> ../../../src/lib/SoftDatabase.cpp:105
> #7  0x000000080211af6a in ~SoftSession (this=0x802418300) at
> ../../../src/lib/SoftSession.cpp:109
> #8  0x000000080211a3a9 in SoftHSMInternal::closeSession
> (this=0x802503600, hSession=Variable "hSession" is not available.
> ) at ../../../src/lib/SoftHSMInternal.cpp:180
> #9  0x000000000041b42e in hsm_session_close ()
> #10 0x000000000041b4ff in hsm_ctx_close ()
> #11 0x000000000041dff5 in hsm_close ()
> #12 0x0000000000404b98 in server_main ()
> #13 0x000000000040967b in main ()



From sara at sinodun.com  Wed Mar  6 10:28:11 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 6 Mar 2013 10:28:11 +0000
Subject: [Opendnssec-develop] RE: Team meeting - Thursday 7 March @ 14:00 CET
References: <2DB5474B-EB1F-4D05-B488-4188A2635C7D@sinodun.com>
Message-ID: <B0E79514-4D48-4A11-819C-A136ABEB302E@sinodun.com>

Hi All, 

We have a team meeting tomorrow:

Date:      Thursday 7 March 2013
Time:      14:00-15:00 CET, 13:00-14:00 GMT
Method:  Google+
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-07+Agenda

Sara.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130306/1057149a/attachment.htm>

From sara at sinodun.com  Wed Mar  6 11:34:32 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 6 Mar 2013 11:34:32 +0000
Subject: [Opendnssec-develop] RE: Versioning scheme
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
Message-ID: <5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>

Hi All, 

The development team had a discussion last year about the versioning scheme used for OpenDNSSEC and the general feeling was that it would make sense to switch from the current component based scheme to an API compatibility based approach. The upcoming release of 1.4 would be a suitable time to change the versioning scheme so I wanted to run this past the board to see if anyone has strong feelings either way before we go ahead with this. The details of the current and proposed scheme are below.

We would obviously need to communicate this change to the users effectively. One impact of the change would probably be to increase the frequency at which the minor versions increased.  We might also have to review how the roadmap refers to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content) and review what maintenance we provide on older releases too.

Regards

Sara.


Current scheme
----------------------------

The current version numbering system based on the following (and also direction from the board about what functionality they would like to see in what release): 

Releases are numbered using the following scheme: <name>-<major>.<minor>.<patch>

	? <name> - The name of the software, e.g. opendnssec or softhsm.
	? <major> - Indicate changes in the overall system design.
	? <minor> - Indicate changes in the components.
	? <patch> - Indicate bug fixes.

In practice 'patch' releases often include updates that extend (and sometimes change) functionality, command utilities and/or log output. 


Proposed scheme
-----------------------------

Something along the lines of  e.g. http://semver.org/ which summarises to:

	? <name> - The name of the software, e.g. opendnssec or softhsm.
	? <major> - Backwards incompatible changes must increase the major version.
	? <minor> - New, backwards compatible functionality, deprecated functionality, or substantial new functionality within private code.
	? <patch> - Only backwards compatible bug fixes.

This does assume a clearly defined API, so there is an argument for postponing any change until there is a unified control interface for ODS but for 1.4 this could be based on the command utilities and database schema. Note that it also doesn't explicitly exclude bumping the major version for major functional changes in private code. 








From jad at sinodun.com  Wed Mar  6 14:32:56 2013
From: jad at sinodun.com (John Dickinson)
Date: Wed, 06 Mar 2013 14:32:56 +0000
Subject: [Opendnssec-develop] Jenkins
In-Reply-To: <E682F024-50E7-4040-804D-85331986EA32@sinodun.com>
References: <E682F024-50E7-4040-804D-85331986EA32@sinodun.com>
Message-ID: <1362580376.38749.1.camel@custard.sinodun.com>

On Fri, 2013-02-01 at 18:10 +0000, John Dickinson wrote:
> I have downgraded jenkins from v1.500 to v1.499 as v1.500 is not loading all jobs. There is a similar bug report already filed against v1.500 - https://issues.jenkins-ci.org/browse/JENKINS-16568 although we are seeing this on a single axis matrix job.
> 
> I have disabled auto updates of jerkins until this is fixed.

I have restarted updates and all seems well. jenkins == v1.504

John




From sara at sinodun.com  Thu Mar  7 14:34:14 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 7 Mar 2013 14:34:14 +0000
Subject: Fwd: [Opendnssec-develop] RE: Team meeting - Thursday 7 March @ 14:00
	CET
References: <B0E79514-4D48-4A11-819C-A136ABEB302E@sinodun.com>
Message-ID: <1963030A-9D5A-488B-984A-54B277173FB1@sinodun.com>

Hi All, 

Minutes from todays meeting are available for review:

https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-07+Minutes

Please note the next meeting is planned for Tuesday 26th March.

Sara.

Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 6 March 2013 10:28:11 GMT
> To: "opendnssec-develop at lists.opendnssec.org Dev" <Opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Team meeting - Thursday 7 March @ 14:00 CET
> 
> Hi All, 
> 
> We have a team meeting tomorrow:
> 
> Date:      Thursday 7 March 2013
> Time:      14:00-15:00 CET, 13:00-14:00 GMT
> Method:  Google+
> Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-07+Agenda
> 
> Sara.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130307/2b4a1ee8/attachment.htm>

From sion at nominet.org.uk  Wed Mar 13 09:30:56 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Wed, 13 Mar 2013 09:30:56 +0000
Subject: [Opendnssec-develop] freeBSD VMs
Message-ID: <51404750.10601@nominet.org.uk>

Morning.

I'm going to tweak the configuration of the logging on the two freebsd
VMs in our Jenkins setup. Basically I'm trying to stop kernel debug
lines getting into our _syslog file (which then confuses tests that
count some expected output).

This shouldn't change anything for you; but if you see some strange
behaviour from those machines (not including segfaults - that is a
separate issue entirely) just let me know.

Sion


From sara at sinodun.com  Wed Mar 13 11:52:21 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Wed, 13 Mar 2013 11:52:21 +0000
Subject: [Opendnssec-develop] RE: Physical Dev meetings @ RIPE 66
Message-ID: <62A2BB3B-0F69-4B88-AE24-9DB6D275207F@sinodun.com>

Hi All, 

We talked in the last team meeting about trying to combine the physical developer meeting with the upcoming RIPE 66 conference. I've created a Doodle:

http://doodle.com/8w9bxvs3s2bv5wp2

to try to gauge everyone's availability during the week of RIPE to see if this is feasible (this assumes everyone is going to RIPE :-) ). The idea would be to try to squeeze 2, maybe 3 meetings in of around 2 hours each if we can find times when everyone is free. Another idea might be to use one slot to do a 'Meet the team' session for ODS users as I understand there may be quite a few new users attending. 

The RIPE meeting plan is here: 
http://doodle.com/r?url=https%3A%2F%2Fripe66.ripe.net%2Fprogramme%2Fmeeting-plan%2F.  

I've blocked out Tuesday pm and the middle of Wednesday on the Doodle for the OAB meeting and DNS sessions respectively. 

Sara.

From Roland.vanRijswijk at surfnet.nl  Thu Mar 14 07:29:10 2013
From: Roland.vanRijswijk at surfnet.nl (Roland van Rijswijk - Deij)
Date: Thu, 14 Mar 2013 08:29:10 +0100
Subject: [Opendnssec-develop] Re: Versioning scheme
In-Reply-To: <5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
Message-ID: <51417C46.3090409@surfnet.nl>

Hi Sara,

Apparently, no one has responded to this one yet, so: bump.

My 2 cents: I have no problem with the proposed scheme.

Cheers,

Roland

Sara Dickinson wrote:
> Hi All, 
> 
> The development team had a discussion last year about the versioning scheme used for OpenDNSSEC and the general feeling was that it would make sense to switch from the current component based scheme to an API compatibility based approach. The upcoming release of 1.4 would be a suitable time to change the versioning scheme so I wanted to run this past the board to see if anyone has strong feelings either way before we go ahead with this. The details of the current and proposed scheme are below.
> 
> We would obviously need to communicate this change to the users effectively. One impact of the change would probably be to increase the frequency at which the minor versions increased.  We might also have to review how the roadmap refers to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content) and review what maintenance we provide on older releases too.
> 
> Regards
> 
> Sara.
> 
> 
> Current scheme
> ----------------------------
> 
> The current version numbering system based on the following (and also direction from the board about what functionality they would like to see in what release): 
> 
> Releases are numbered using the following scheme: <name>-<major>.<minor>.<patch>
> 
> 	? <name> - The name of the software, e.g. opendnssec or softhsm.
> 	? <major> - Indicate changes in the overall system design.
> 	? <minor> - Indicate changes in the components.
> 	? <patch> - Indicate bug fixes.
> 
> In practice 'patch' releases often include updates that extend (and sometimes change) functionality, command utilities and/or log output. 
> 
> 
> Proposed scheme
> -----------------------------
> 
> Something along the lines of  e.g. http://semver.org/ which summarises to:
> 
> 	? <name> - The name of the software, e.g. opendnssec or softhsm.
> 	? <major> - Backwards incompatible changes must increase the major version.
> 	? <minor> - New, backwards compatible functionality, deprecated functionality, or substantial new functionality within private code.
> 	? <patch> - Only backwards compatible bug fixes.
> 
> This does assume a clearly defined API, so there is an argument for postponing any change until there is a unified control interface for ODS but for 1.4 this could be based on the command utilities and database schema. Note that it also doesn't explicitly exclude bumping the major version for major functional changes in private code. 
> 
> 
> 
> 
> 
> 

-- 
-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surfnet.nl/en/
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl


From ondrej at sury.org  Thu Mar 14 09:37:15 2013
From: ondrej at sury.org (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Thu, 14 Mar 2013 10:37:15 +0100
Subject: [Opendnssec-develop] Re: Versioning scheme
In-Reply-To: <51417C46.3090409@surfnet.nl>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
	<51417C46.3090409@surfnet.nl>
Message-ID: <CALjhHG_ES5-gmV2D75x6Z7rTtP4RSF4aM68eCAUZfAu20_C6nA@mail.gmail.com>

Yep, I agree. This is fine with me.

O.


On Thu, Mar 14, 2013 at 8:29 AM, Roland van Rijswijk - Deij <
Roland.vanRijswijk at surfnet.nl> wrote:

> Hi Sara,
>
> Apparently, no one has responded to this one yet, so: bump.
>
> My 2 cents: I have no problem with the proposed scheme.
>
> Cheers,
>
> Roland
>
> Sara Dickinson wrote:
> > Hi All,
> >
> > The development team had a discussion last year about the versioning
> scheme used for OpenDNSSEC and the general feeling was that it would make
> sense to switch from the current component based scheme to an API
> compatibility based approach. The upcoming release of 1.4 would be a
> suitable time to change the versioning scheme so I wanted to run this past
> the board to see if anyone has strong feelings either way before we go
> ahead with this. The details of the current and proposed scheme are below.
> >
> > We would obviously need to communicate this change to the users
> effectively. One impact of the change would probably be to increase the
> frequency at which the minor versions increased.  We might also have to
> review how the roadmap refers to future releases since version numbers
> would not be guaranteed (e.g. we could use names not numbers to label
> releases with specific content) and review what maintenance we provide on
> older releases too.
> >
> > Regards
> >
> > Sara.
> >
> >
> > Current scheme
> > ----------------------------
> >
> > The current version numbering system based on the following (and also
> direction from the board about what functionality they would like to see in
> what release):
> >
> > Releases are numbered using the following scheme:
> <name>-<major>.<minor>.<patch>
> >
> >       ? <name> - The name of the software, e.g. opendnssec or softhsm.
> >       ? <major> - Indicate changes in the overall system design.
> >       ? <minor> - Indicate changes in the components.
> >       ? <patch> - Indicate bug fixes.
> >
> > In practice 'patch' releases often include updates that extend (and
> sometimes change) functionality, command utilities and/or log output.
> >
> >
> > Proposed scheme
> > -----------------------------
> >
> > Something along the lines of  e.g. http://semver.org/ which summarises
> to:
> >
> >       ? <name> - The name of the software, e.g. opendnssec or softhsm.
> >       ? <major> - Backwards incompatible changes must increase the major
> version.
> >       ? <minor> - New, backwards compatible functionality, deprecated
> functionality, or substantial new functionality within private code.
> >       ? <patch> - Only backwards compatible bug fixes.
> >
> > This does assume a clearly defined API, so there is an argument for
> postponing any change until there is a unified control interface for ODS
> but for 1.4 this could be based on the command utilities and database
> schema. Note that it also doesn't explicitly exclude bumping the major
> version for major functional changes in private code.
> >
> >
> >
> >
> >
> >
>
> --
> -- Roland M. van Rijswijk - Deij
> -- SURFnet bv
> -- w: http://www.surfnet.nl/en/
> -- t: +31-30-2305388
> -- e: roland.vanrijswijk at surfnet.nl
>



-- 
?Ond?ej Sur? <ondrej at sury.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130314/8aad83b1/attachment.htm>

From sara at sinodun.com  Thu Mar 14 09:50:50 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 14 Mar 2013 09:50:50 +0000
Subject: [Opendnssec-develop] RE: 1.4.0rc3 release 
Message-ID: <6927C964-85E8-4957-AA9C-C583DD6FAB3B@sinodun.com>

Hi All,

Just a reminder that we plan to do a 1.4.0rc3 release tomorrow morning. As far as I know there are no updates for the NEWS file since the b3 release... 

Regards

Sara.

From nick.vandenheuvel at sidn.nl  Thu Mar 14 12:24:30 2013
From: nick.vandenheuvel at sidn.nl (Nick van den Heuvel)
Date: Thu, 14 Mar 2013 12:24:30 +0000
Subject: [Opendnssec-develop] Re: Versioning scheme
In-Reply-To: <51417C46.3090409@surfnet.nl>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
	<51417C46.3090409@surfnet.nl>
Message-ID: <8379DE00FDBE1B4F95522D088EC260DD3F44C62F@kambx2.SIDN.local>

No comments from my side. Looks fine!

-----Original Message-----
From: opendnssec-develop-bounces at lists.opendnssec.org [mailto:opendnssec-develop-bounces at lists.opendnssec.org] On Behalf Of Roland van Rijswijk - Deij
Sent: donderdag 14 maart 2013 8:29
To: Sara Dickinson
Cc: oab at opendnssec.org; opendnssec-develop at lists.opendnssec.org Dev
Subject: [Opendnssec-develop] Re: Versioning scheme

Hi Sara,

Apparently, no one has responded to this one yet, so: bump.

My 2 cents: I have no problem with the proposed scheme.

Cheers,

Roland

Sara Dickinson wrote:
> Hi All, 
> 
> The development team had a discussion last year about the versioning scheme used for OpenDNSSEC and the general feeling was that it would make sense to switch from the current component based scheme to an API compatibility based approach. The upcoming release of 1.4 would be a suitable time to change the versioning scheme so I wanted to run this past the board to see if anyone has strong feelings either way before we go ahead with this. The details of the current and proposed scheme are below.
> 
> We would obviously need to communicate this change to the users effectively. One impact of the change would probably be to increase the frequency at which the minor versions increased.  We might also have to review how the roadmap refers to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content) and review what maintenance we provide on older releases too.
> 
> Regards
> 
> Sara.
> 
> 
> Current scheme
> ----------------------------
> 
> The current version numbering system based on the following (and also direction from the board about what functionality they would like to see in what release): 
> 
> Releases are numbered using the following scheme: <name>-<major>.<minor>.<patch>
> 
> 	* <name> - The name of the software, e.g. opendnssec or softhsm.
> 	* <major> - Indicate changes in the overall system design.
> 	* <minor> - Indicate changes in the components.
> 	* <patch> - Indicate bug fixes.
> 
> In practice 'patch' releases often include updates that extend (and sometimes change) functionality, command utilities and/or log output. 
> 
> 
> Proposed scheme
> -----------------------------
> 
> Something along the lines of  e.g. http://semver.org/ which summarises to:
> 
> 	* <name> - The name of the software, e.g. opendnssec or softhsm.
> 	* <major> - Backwards incompatible changes must increase the major version.
> 	* <minor> - New, backwards compatible functionality, deprecated functionality, or substantial new functionality within private code.
> 	* <patch> - Only backwards compatible bug fixes.
> 
> This does assume a clearly defined API, so there is an argument for postponing any change until there is a unified control interface for ODS but for 1.4 this could be based on the command utilities and database schema. Note that it also doesn't explicitly exclude bumping the major version for major functional changes in private code. 
> 
> 
> 
> 
> 
> 

-- 
-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surfnet.nl/en/
-- t: +31-30-2305388
-- e: roland.vanrijswijk at surfnet.nl
_______________________________________________
Opendnssec-develop mailing list
Opendnssec-develop at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop


From jakob at kirei.se  Thu Mar 14 13:00:20 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Thu, 14 Mar 2013 14:00:20 +0100
Subject: [Opendnssec-develop] Re: Versioning scheme
In-Reply-To: <5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
Message-ID: <AB5E1556-95FB-4C8E-9B56-F59A0FC7F0C5@kirei.se>

I'm all good with this scheme.

	jakob

-- 
Jakob Schlyter
Kirei AB - http://www.kirei.se/



From jacques.latour at cira.ca  Thu Mar 14 12:44:07 2013
From: jacques.latour at cira.ca (Jacques Latour)
Date: Thu, 14 Mar 2013 08:44:07 -0400
Subject: [Opendnssec-develop] RE: Versioning scheme
In-Reply-To: <CALjhHG_ES5-gmV2D75x6Z7rTtP4RSF4aM68eCAUZfAu20_C6nA@mail.gmail.com>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
	<51417C46.3090409@surfnet.nl>
	<CALjhHG_ES5-gmV2D75x6Z7rTtP4RSF4aM68eCAUZfAu20_C6nA@mail.gmail.com>
Message-ID: <CF3C66A5DB184445AE42748BFA64AAA101264BCAA7D3@MBX01.cira1.cira.ca>

Same here.

From: oab at opendnssec.org [mailto:oab at opendnssec.org] On Behalf Of Ondrej Sur?
Sent: March-14-13 5:37 AM
To: Roland van Rijswijk - Deij
Cc: Sara Dickinson; oab at opendnssec.org; opendnssec-develop at lists.opendnssec.org Dev
Subject: Re: Versioning scheme

Yep, I agree. This is fine with me.

O.

On Thu, Mar 14, 2013 at 8:29 AM, Roland van Rijswijk - Deij <Roland.vanRijswijk at surfnet.nl<mailto:Roland.vanRijswijk at surfnet.nl>> wrote:
Hi Sara,

Apparently, no one has responded to this one yet, so: bump.

My 2 cents: I have no problem with the proposed scheme.

Cheers,

Roland

Sara Dickinson wrote:
> Hi All,
>
> The development team had a discussion last year about the versioning scheme used for OpenDNSSEC and the general feeling was that it would make sense to switch from the current component based scheme to an API compatibility based approach. The upcoming release of 1.4 would be a suitable time to change the versioning scheme so I wanted to run this past the board to see if anyone has strong feelings either way before we go ahead with this. The details of the current and proposed scheme are below.
>
> We would obviously need to communicate this change to the users effectively. One impact of the change would probably be to increase the frequency at which the minor versions increased.  We might also have to review how the roadmap refers to future releases since version numbers would not be guaranteed (e.g. we could use names not numbers to label releases with specific content) and review what maintenance we provide on older releases too.
>
> Regards
>
> Sara.
>
>
> Current scheme
> ----------------------------
>
> The current version numbering system based on the following (and also direction from the board about what functionality they would like to see in what release):
>
> Releases are numbered using the following scheme: <name>-<major>.<minor>.<patch>
>
>       ? <name> - The name of the software, e.g. opendnssec or softhsm.
>       ? <major> - Indicate changes in the overall system design.
>       ? <minor> - Indicate changes in the components.
>       ? <patch> - Indicate bug fixes.
>
> In practice 'patch' releases often include updates that extend (and sometimes change) functionality, command utilities and/or log output.
>
>
> Proposed scheme
> -----------------------------
>
> Something along the lines of  e.g. http://semver.org/ which summarises to:
>
>       ? <name> - The name of the software, e.g. opendnssec or softhsm.
>       ? <major> - Backwards incompatible changes must increase the major version.
>       ? <minor> - New, backwards compatible functionality, deprecated functionality, or substantial new functionality within private code.
>       ? <patch> - Only backwards compatible bug fixes.
>
> This does assume a clearly defined API, so there is an argument for postponing any change until there is a unified control interface for ODS but for 1.4 this could be based on the command utilities and database schema. Note that it also doesn't explicitly exclude bumping the major version for major functional changes in private code.
>
>
>
>
>
>
--
-- Roland M. van Rijswijk - Deij
-- SURFnet bv
-- w: http://www.surfnet.nl/en/
-- t: +31-30-2305388<tel:%2B31-30-2305388>
-- e: roland.vanrijswijk at surfnet.nl<mailto:roland.vanrijswijk at surfnet.nl>



--
?Ond?ej Sur? <ondrej at sury.org<mailto:ondrej at sury.org>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130314/b8c453d2/attachment.htm>

From joe.abley at icann.org  Thu Mar 14 13:28:57 2013
From: joe.abley at icann.org (Joe Abley)
Date: Thu, 14 Mar 2013 06:28:57 -0700
Subject: [Opendnssec-develop] Re: Versioning scheme
In-Reply-To: <AB5E1556-95FB-4C8E-9B56-F59A0FC7F0C5@kirei.se>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
	<AB5E1556-95FB-4C8E-9B56-F59A0FC7F0C5@kirei.se>
Message-ID: <9E775DBB-62A4-468F-902D-7B92E2755BF2@icann.org>

No complaints here. Apologies for not replying earlier. 

Aue Te Ariki! He toki ki roto taku mahuna!

On 2013-03-14, at 9:00, "Jakob Schlyter" <jakob at kirei.se> wrote:

> I'm all good with this scheme.
> 
>    jakob
> 
> -- 
> Jakob Schlyter
> Kirei AB - http://www.kirei.se/
> 


From olaf at NLnetLabs.nl  Thu Mar 14 13:46:03 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Thu, 14 Mar 2013 09:46:03 -0400
Subject: [Opendnssec-develop] Re: Versioning scheme
In-Reply-To: <51417C46.3090409@surfnet.nl>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
	<51417C46.3090409@surfnet.nl>
Message-ID: <C9F1B1E9-1A89-4281-930E-C1BC264C2AAE@NLnetLabs.nl>


WFM, one question though.


On Mar 14, 2013, at 3:29 AM, Roland van Rijswijk - Deij <Roland.vanRijswijk at surfnet.nl> wrote:

>> Proposed scheme
>> -----------------------------
>> 
>> Something along the lines of  e.g. http://semver.org/ which summarises to:
>> 
>> 	? <name> - The name of the software, e.g. opendnssec or softhsm.
>> 	? <major> - Backwards incompatible changes must increase the major version.
>> 	? <minor> - New, backwards compatible functionality, deprecated functionality, or substantial new functionality within private code.

I read this as:
deprecated functionality while maintaining backward compatibility. 

It is probably good to make that explicit.



--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
olaf at NLnetLabs.nl

Science Park 400, 1098 XH Amsterdam, The Netherlands



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130314/1e4526e0/attachment.htm>

From sara at sinodun.com  Thu Mar 14 16:45:46 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 14 Mar 2013 16:45:46 +0000
Subject: [Opendnssec-develop] Re: Versioning scheme
In-Reply-To: <C9F1B1E9-1A89-4281-930E-C1BC264C2AAE@NLnetLabs.nl>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<5361971B-2A10-46A5-8E80-E13F9D7DBB5F@sinodun.com>
	<51417C46.3090409@surfnet.nl>
	<C9F1B1E9-1A89-4281-930E-C1BC264C2AAE@NLnetLabs.nl>
Message-ID: <3DEEF55A-5164-43BB-93D1-4FC100FE3403@sinodun.com>


On 14 Mar 2013, at 13:46, Olaf Kolkman wrote:

> 
> I read this as:
> deprecated functionality while maintaining backward compatibility. 

Indeed.

> 
> It is probably good to make that explicit.
> 

Will do - thanks. 

Thanks for all the responses/feedback - I think we have reached consensus!

Sara.



From sara at sinodun.com  Fri Mar 15 10:29:27 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 15 Mar 2013 10:29:27 +0000
Subject: [Opendnssec-develop] RE: jenkins emails
Message-ID: <251FBE49-CCB4-4951-BAAE-7406D3C06BFA@sinodun.com>

Hi All, 

Sorry for the recent flood of jenkins emails. Between trying to fix solaris problems and understand the very strange goings on with FreeBSD at the moment we are trying various rebuilds to fix things!

Sara.

From sara at sinodun.com  Mon Mar 18 14:04:37 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 18 Mar 2013 14:04:37 +0000
Subject: [Opendnssec-develop] RE: Jenkins weekly clean build jobs
Message-ID: <D8F0A38F-8276-42D7-B447-66CC39DB8606@sinodun.com>

Hi All, 

FYI - I am setting up weekly jobs that will clean out the build and test areas for each of the jenkins OpenDNSSEC branch/DB combinations and then trigger a full build. I've moved the daily test jobs to a slightly later time and I have also had to slightly change the way the build jobs are chained together to accommodate this. The new job schedule is detailed on the testing page:

https://wiki.opendnssec.org/display/OpenDNSSEC/Testing#Testing-Buildschedule

Comments/suggestions on this approach welcomed!

Sara.




From sara at sinodun.com  Mon Mar 18 17:12:11 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 18 Mar 2013 17:12:11 +0000
Subject: [Opendnssec-develop] RE: Solaris t2000 sparc64 added to jenkins
Message-ID: <558895D0-0529-4CB3-A64A-363EDD3BB43F@sinodun.com>

Hi All, 

The t2000 server donated by Nominet has finally been added as a jenkins slave: solaris-t2000-sparc64-ods16. Note that since it is a physical machine it has different IP address to the virtual machines - see here:

https://wiki.opendnssec.org/pages/viewpage.action?pageId=2064460

It is currently only enabled in the sqlite jobs on 1.3 and trunk. Build issues with mysql and enforcer-ng and SoftHSMv2 will (I think) require patching the m4 macros so I haven't got round to that yet... 

All the test cases but one passed - on trunk the general.pindemon.logon_and_logoff test was crashing when running from the jenkins job, however I could not reproduce the crash on the command line or in a local workspace... I've disabled this job on solaris for now while I investigate :-(

I have also updated the script that extracts information from the test cases to support a #DISABLED comment tag so that details can be added as to why tests are turned off on certain platforms. 

Sara.



From jerry at opendnssec.org  Thu Mar 21 08:38:33 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 21 Mar 2013 09:38:33 +0100
Subject: [Opendnssec-develop] Maintenance of dist.opendnssec.org and SVN
	today Thursday 14:00 - 14:30 CET
Message-ID: <09C1FE7C-E8E5-49C6-AC7D-8538F9D1A8BD@opendnssec.org>

Hi,

Need to do some maintenance on dist/SVN today. Please don't use SVN during this time.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130321/f3e7a3ff/attachment.bin>

From jerry at opendnssec.org  Thu Mar 21 13:31:52 2013
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 21 Mar 2013 14:31:52 +0100
Subject: [Opendnssec-develop] Re: Maintenance of dist.opendnssec.org and SVN
	today Thursday 14:00 - 14:30 CET
In-Reply-To: <09C1FE7C-E8E5-49C6-AC7D-8538F9D1A8BD@opendnssec.org>
References: <09C1FE7C-E8E5-49C6-AC7D-8538F9D1A8BD@opendnssec.org>
Message-ID: <A049ECDC-8E63-4E4E-8D30-8BB5CF4A82B4@opendnssec.org>

On Mar 21, 2013, at 09:38 , Jerry Lundstr?m wrote:

> Need to do some maintenance on dist/SVN today. Please don't use SVN during this time.


All done.

--
Jerry Lundstr?m - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130321/cc669729/attachment.bin>

From sion at nominet.org.uk  Mon Mar 25 09:27:25 2013
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Mon, 25 Mar 2013 09:27:25 +0000
Subject: [Opendnssec-develop] Jenkins
Message-ID: <5150187D.5030807@nominet.org.uk>

Is anyone else seeing "no jobs" on the Jenkins homepage?

I've been away so have not looked at jenkins since Tuesday of last
week... Is this a new thing or has it been like this for a while?

Sion


From sara at sinodun.com  Mon Mar 25 10:21:29 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 25 Mar 2013 10:21:29 +0000
Subject: [Opendnssec-develop] Jenkins
In-Reply-To: <5150187D.5030807@nominet.org.uk>
References: <5150187D.5030807@nominet.org.uk>
Message-ID: <2A8F2D1B-7746-4BF7-85E3-CDF7468D2797@sinodun.com>

Just having a look....

Sara.

On 25 Mar 2013, at 09:27, Si?n Lloyd wrote:

> Is anyone else seeing "no jobs" on the Jenkins homepage?
> 
> I've been away so have not looked at jenkins since Tuesday of last
> week... Is this a new thing or has it been like this for a while?
> 
> Sion
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From jad at sinodun.com  Mon Mar 25 10:41:19 2013
From: jad at sinodun.com (John Dickinson)
Date: Mon, 25 Mar 2013 10:41:19 +0000
Subject: [Opendnssec-develop] Jenkins
In-Reply-To: <5150187D.5030807@nominet.org.uk>
References: <5150187D.5030807@nominet.org.uk>
Message-ID: <4EBBD144-C6D2-49D4-8065-6CD8DDADA551@sinodun.com>

Caused by a bug in jenkins 1.507 - reverted to 1.506. See 

https://issues.jenkins-ci.org/browse/JENKINS-17337

I am going to stop automatic updates until they fix it.

John


On 25 Mar 2013, at 09:27, Si?n Lloyd <sion at nominet.org.uk> wrote:

> Is anyone else seeing "no jobs" on the Jenkins homepage?
> 
> I've been away so have not looked at jenkins since Tuesday of last
> week... Is this a new thing or has it been like this for a while?
> 
> Sion
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



---
jad at sinodun.com

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957



From jad at sinodun.com  Mon Mar 25 10:46:38 2013
From: jad at sinodun.com (John Dickinson)
Date: Mon, 25 Mar 2013 10:46:38 +0000
Subject: [Opendnssec-develop] Jenkins
In-Reply-To: <4EBBD144-C6D2-49D4-8065-6CD8DDADA551@sinodun.com>
References: <5150187D.5030807@nominet.org.uk>
	<4EBBD144-C6D2-49D4-8065-6CD8DDADA551@sinodun.com>
Message-ID: <3CE71FCE-D61B-4883-B622-BB431D18A401@sinodun.com>

BTW Has anyone tried Atlassian's bamboo ci server?

http://www.atlassian.com/software/bamboo/overview

It might be more stable than jenkins.

John

On 25 Mar 2013, at 10:41, John Dickinson <jad at sinodun.com> wrote:

> Caused by a bug in jenkins 1.507 - reverted to 1.506. See 
> 
> https://issues.jenkins-ci.org/browse/JENKINS-17337
> 
> I am going to stop automatic updates until they fix it.
> 
> John
> 
> 
> On 25 Mar 2013, at 09:27, Si?n Lloyd <sion at nominet.org.uk> wrote:
> 
>> Is anyone else seeing "no jobs" on the Jenkins homepage?
>> 
>> I've been away so have not looked at jenkins since Tuesday of last
>> week... Is this a new thing or has it been like this for a while?
>> 
>> Sion
>> _______________________________________________
>> Opendnssec-develop mailing list
>> Opendnssec-develop at lists.opendnssec.org
>> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 
> 
> 
> ---
> jad at sinodun.com
> 
> http://sinodun.com
> 
> Sinodun Internet Technologies Ltd.
> Stables 4, Suite 11,
> Howbery Park,
> Wallingford,
> Oxfordshire,
> OX10 8BA,
> U.K.
> 
> +44 (0)1491 834957
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From sara at sinodun.com  Mon Mar 25 11:02:17 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 25 Mar 2013 11:02:17 +0000
Subject: [Opendnssec-develop] RE: Team meeting - Thursday 26 March @ 14:00
	CET
References: <B0E79514-4D48-4A11-819C-A136ABEB302E@sinodun.com>
Message-ID: <5DB6F213-E704-49E7-B9C0-59D2F931FCA2@sinodun.com>

Hi All, 

We have a team meeting tomorrow:

Date:      Tuesday 26 March 2013
Time:      14:00-15:00 CET, 13:00-14:00 GMT
Method:  Google+
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-26+Agenda

I've added an item to the agenda to review all the issues currently planned for 1.4.1 - Sion/Matthijs/Jakob if you have a few minutes before the meeting can you take a look through the issues assigned to you for 1.4.1rc1 so we can review what to do with them?

Sara.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130325/83de352b/attachment.htm>

From sara at sinodun.com  Tue Mar 26 10:53:22 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 26 Mar 2013 10:53:22 +0000
Subject: Fwd: [Opendnssec-develop] RE: Team meeting - Tuesday 26 March @ 14:00
	CET
References: <5DB6F213-E704-49E7-B9C0-59D2F931FCA2@sinodun.com>
Message-ID: <E86E6253-87F8-459F-B520-2DBAC348BCC1@sinodun.com>

Of course I meant Tuesday (today), not Thursday.... sorry for the incorrect day in the subject.

Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 25 March 2013 11:02:17 GMT
> To: "opendnssec-develop at lists.opendnssec.org Dev" <Opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Team meeting - Thursday 26 March @ 14:00 CET
> 
> Hi All, 
> 
> We have a team meeting tomorrow:
> 
> Date:      Tuesday 26 March 2013
> Time:      14:00-15:00 CET, 13:00-14:00 GMT
> Method:  Google+
> Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-26+Agenda
> 
> I've added an item to the agenda to review all the issues currently planned for 1.4.1 - Sion/Matthijs/Jakob if you have a few minutes before the meeting can you take a look through the issues assigned to you for 1.4.1rc1 so we can review what to do with them?
> 
> Sara.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20130326/286afc65/attachment.htm>

From sara at sinodun.com  Tue Mar 26 11:21:59 2013
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 26 Mar 2013 11:21:59 +0000
Subject: [Opendnssec-develop] RE: Team meeting - Tuesday 26 March @ 14:00
	CET
In-Reply-To: <E86E6253-87F8-459F-B520-2DBAC348BCC1@sinodun.com>
References: <5DB6F213-E704-49E7-B9C0-59D2F931FCA2@sinodun.com>
	<E86E6253-87F8-459F-B520-2DBAC348BCC1@sinodun.com>
Message-ID: <57623371-2D6F-4883-A4E9-955EE56298AA@sinodun.com>

And an incorrect agenda link.... what can I say... it was Monday morning ;-)

Agenda: https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-26+Agenda


On 26 Mar 2013, at 10:53, Sara Dickinson wrote:

> Of course I meant Tuesday (today), not Thursday.... sorry for the incorrect day in the subject.
> 
> Begin forwarded message:
> 
>> From: Sara Dickinson <sara at sinodun.com>
>> Date: 25 March 2013 11:02:17 GMT
>> To: "opendnssec-develop at lists.opendnssec.org Dev" <Opendnssec-develop at lists.opendnssec.org>
>> Subject: [Opendnssec-develop] RE: Team meeting - Thursday 26 March @ 14:00 CET
>> 
>> Hi All, 
>> 
>> We have a team meeting tomorrow:
>> 
>> Date:      Tuesday 26 March 2013
>> Time:      14:00-15:00 CET, 13:00-14:00 GMT
>> Method:  Google+
>> Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-26+Agenda
>> 
>> I've added an item to the agenda to review all the issues currently planned for 1.4.1 - Sion/Matthijs/Jakob if you have a few minutes before the meeting can you take a look through the issues assigned to you for 1.4.1rc1 so we can review what to do with them?
>> 
>> Sara.
>> 
>> _______________________________________________
>> 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



From rick at openfortress.nl  Wed Mar 27 15:33:02 2013
From: rick at openfortress.nl (Rick van Rein (OpenFortress))
Date: Wed, 27 Mar 2013 16:33:02 +0100
Subject: [Opendnssec-develop] Minutes 2013-03-26
Message-ID: <34D1176D-F9EA-449D-BB73-4123C613192B@openfortress.nl>

Hello,

Yesterday's meeting notes have popped up online:

https://wiki.opendnssec.org/display/OpenDNSSEC/2013-03-26+Minutes

Clarifications and changes -> ask me or just help yourself :)

Enjoy,
 -Rick