From sara at sinodun.com  Sun Dec  2 15:30:39 2012
From: sara at sinodun.com (Sara (Sinodun))
Date: Sun, 2 Dec 2012 15:30:39 +0000
Subject: [Opendnssec-develop] RE: Team Meeting - Monday 3rd Dec @ 14.00 CET
References: <E30A2A73-3F25-441F-A62A-0764C00A2CD6@sinodun.com>
Message-ID: <B0DF8E63-F364-48F0-87A9-28B36F78574A@sinodun.com>

Hi All, 

Lets try this again! We have a team meeting Monday:

Date:      Monday 3 December 2012
Time:      14:00-15:00 CET, 13:00-14:00 GMT
Method:  Google+
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2012-11-27+agenda

Sara.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121202/193abc6c/attachment.htm>

From sara at sinodun.com  Mon Dec  3 10:46:32 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 3 Dec 2012 10:46:32 +0000
Subject: [Opendnssec-develop] Re: [Opendnssec-user] syntax error in
	zonelist.xml -> destruction
In-Reply-To: <CALjhHG_vvWwRJhxoddZfPy1=w2oq6=tKDbpwVmWPJmQxj5H+jQ@mail.gmail.com>
References: <50AA5F03.5090708@uvt.nl>
	<45B49AA5-9641-4895-9E21-E90FC43B3F5B@sinodun.com>
	<50AB75AB.9050209@uvt.nl>
	<CALjhHG_xaYHQR2WR2Pqn-d-f5gjga_EnQPVT8izSyft2ud5hBw@mail.gmail.com>
	<50ABA9C0.6080401@nominet.org.uk>
	<CALjhHG9TD7ixWpPH4kT5o9qGTx48VgVmacs_D9f=uujMa70h_A@mail.gmail.com>
	<50ABADA1.9050209@nominet.org.uk> <50AC9AE9.7050403@nlnetlabs.nl>
	<CALjhHG8Ds0p96PJu0_61uhdMFp5po6fknLc2X8kTx8_Kq8PPWg@mail.gmail.com>
	<50B4BB80.9080104@nlnetlabs.nl>
	<80EB6542-5747-45D6-8A47-562D0C681884@sinodun.com>
	<CALjhHG_vvWwRJhxoddZfPy1=w2oq6=tKDbpwVmWPJmQxj5H+jQ@mail.gmail.com>
Message-ID: <9581CA05-DF72-45C7-BA3E-862ACB7C4785@sinodun.com>


On 3 Dec 2012, at 10:15, Ond?ej Sur? wrote:

> On Mon, Dec 3, 2012 at 11:08 AM, Sara Dickinson <sara at sinodun.com> wrote:
>> Hi both,
>> 
>> I'm just trying to catch up as I was out last week. So which issue have been back ported to 1.3.9?
> 
> http://packages.qa.debian.org/o/opendnssec/news/20121127T150427Z.html

Many thanks!

> 
>> Is it the case that since we don't use git (hint noted Ond?ej  :-)  ) we need to (understandably) provide patches to maintainers if we want something patched?
> 
> Well, since I have a suicidal tendencies every time I need to use
> subversion, this (providing patches) would be very much helpful. Same
> with security updates for stable releases (once Debian is released).

> Just pointing to the right patch in the fisheye is sufficient ? well,
> and some help in case the patch is scattered across multiple commits.

Ack.

> 
> Ondrej
> 



From sara at sinodun.com  Mon Dec  3 11:36:21 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 3 Dec 2012 11:36:21 +0000
Subject: [Opendnssec-develop] RE: Versioning and version support
In-Reply-To: <50B3703E.6040902@nominet.org.uk>
References: <2F5E77E6-B22F-4D38-A95A-6E18200F0CB7@sinodun.com>
	<50B3703E.6040902@nominet.org.uk>
Message-ID: <C432AE52-7E11-4AEC-9AD0-CB8A39E1468C@sinodun.com>


On 26 Nov 2012, at 13:35, Si?n Lloyd wrote:

> I think that this would be good, note however the text for major version
> number says "Major version X (X.y.z | X > 0) MUST be incremented if any
> backwards incompatible changes are introduced to the public API."
> 
> So that doesn't preclude enforcer-ng being 2.0 even if the API didn't
> change at all if I read it correctly?

Well, it depends if you consider the database schema part of the API I suppose......

But I think your point is that we would still be free to bump versions numbers based on the magnitude of functional changes. And I think the answer is yes, but (IMHO) it could be very confusing for users if we mix and match....  I think this versioning scheme makes a lot of sense for a library because it is aimed at managing dependancies, but for a complex application it does have some drawbacks.... 

> It also means new functionality
> doesn't have to bump the major version.

Indeed - if you just add new stuff it is just a minor version. So this really is quite a change from how we do things now. 

Sara.

> 
> Sion
> 



From matthijs at nlnetlabs.nl  Mon Dec  3 14:19:45 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 03 Dec 2012 15:19:45 +0100
Subject: [Opendnssec-develop] 1.3.12 ready for release
Message-ID: <50BCB501.9020509@nlnetlabs.nl>

Updated the KNOWN_ISSUES file.

1... 3... 12... Ready for take-off!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121203/90f7db12/attachment.bin>

From sara at sinodun.com  Mon Dec  3 14:46:17 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 3 Dec 2012 14:46:17 +0000
Subject: Fwd: [Opendnssec-develop] RE: Regression testing update
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
Message-ID: <A5635504-28E7-4410-8F39-F9A47FAC6C77@sinodun.com>

As a follow up to the meeting today... I would like to move ahead with this later this week so if people have time to review it will be greatly appreciated! 

Sara.

Begin forwarded message:

> From: Sara Dickinson <sara at sinodun.com>
> Date: 26 November 2012 15:03:12 GMT
> To: "opendnssec-develop at lists.opendnssec.org Dev" <Opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Regression testing update
> 
> Hi All, 
> 
> So I have been having another look lately at the regression tests and how we could manage them better as we add more tests. (They are currently a mixture of imported scripts with a numeric naming convention and new tests added by us.) My plan is to do the following things:
> 
> - come up with a new naming convention for the test scripts
> - come up with a way to track what is currently tested (including bug fixes)
> - review which tests should be smoke/daily/weekly
> - re-vamp the Test Coverage wiki page to more clearly see what tests still need adding
> 
> I've had a go at the first two so am looking for some feedback before moving any further.... More details on both the following suggestions are on the wiki page: https://wiki.opendnssec.org/display/OpenDNSSEC/Test+case+policy
> 
> Naming
> -------------
> My idea for naming is to split the names into 3 parts (based on the area tested - see the wiki). These parts would be separated by dashes, with word separated by underscores within the 3 parts. So for example we might have:
> 
> enforcer-keys-check_backup_required_works
> signer-adaptors-many_dns_updates
> general-repository-opendnssecXXX
> 
> I thought this was easier than using than a numbering system and since we currently run all the tests regardless of any failures then the ordering within the directory doesn't really matter (at the moment anyway). We could alternatively use a directory structure along these lines but I'm not convinced that having to always drill down further to the test scripts ultimately makes life easier...? Please let me know if you can think of improvements or alternatives to this. 
> 
> Tracking
> -------------
> On the tracking side of things I took the approach that the most reliable way to track things is to have a way to grab information directly from the tests rather than try to have a separate document that needs updating and so is likely to get out of date. I have written a small script that grabs info from the comments in the test scripts and generates a CSV file as output. It needs more work and really should be incorporated into the framework if we decide to adopt this approach - at the moment it is just to generate feedback. An example excel spreadsheet generated from the information extracted (including new suggested names for the existing tests) is attached to the wiki page for people to review. 
> 
> This does rely on the comments in the tests being accurate and up to date but that seems a good idea anyway!  Please try this out and let me know if you think this approach makes sense. 
> 
> Sara.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From sara at sinodun.com  Tue Dec  4 09:52:51 2012
From: sara at sinodun.com (Sara (Sinodun))
Date: Tue, 4 Dec 2012 09:52:51 +0000
Subject: [Opendnssec-develop] RE: 1.3.12 release candidate
In-Reply-To: <624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>
References: <F168587B-17DC-4962-BA43-036F349B9685@sinodun.com>
	<624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>
Message-ID: <7439038D-CE32-4BF7-B98F-B1F80320D80E@sinodun.com>

All, 

1.3.12 was released yesterday so the branch is open for updates again.

Sara.


On 26 Nov 2012, at 14:05, Sara Dickinson wrote:

> All, 
> 
> Since we have a release candidate issued please refrain from submitting routine code into the 1.3.12 branch until the full release is done. If you have a high priority issue that you believe warrants the re-issue of the release candidate please email the developers list first so this can be agreed.
> 
> Sara.
> 
> Begin forwarded message:
> 

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

From sara at sinodun.com  Tue Dec  4 15:28:49 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 4 Dec 2012 15:28:49 +0000
Subject: [Opendnssec-develop] Re: Access to OpenDNSSEC Wiki
In-Reply-To: <50BCAF4A.1060706@uvt.nl>
References: <50BCAF4A.1060706@uvt.nl>
Message-ID: <E038B942-504E-458C-B2F9-FB3780568427@sinodun.com>

Hi Casper/Rick/Roland,

As discussed I have looked into setting up an area on the OpenDNSSEC wiki where users will be able to contribute content. I chose to set up a separate area (or 'space' in Confluence-speak) for this as it simplifies permissions and separates the content clearly from the main documentation pages. The home page for this area is here:

https://wiki.opendnssec.org/display/USERDOCREF/OpenDNSSEC+User+Reference+Material

I hope this covers the kind of thing you had in mind - comments on the content (and disclaimer!) are welcomed.

I hope that Casper should now have the correct permissions to edit this, as will any registered wiki user with the right permissions. I haven't linked it up to the main documentation yet as I would like some feedback, and I also have a minor permissions question for Jerry who is away until next week. When this is resolved I will link if from the 'Reference Material' page of the main documentation and make an announcement to the user list. I've got a couple of other presentations I can think of that would be good to add here so in the mean time I'll check with the authors if they are happy with that. 

Sara.

From sara at sinodun.com  Tue Dec  4 15:40:09 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 4 Dec 2012 15:40:09 +0000
Subject: [Opendnssec-develop] RE: Process for tracking bugs
Message-ID: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>

Hi All, 

As a follow up to the team meeting yesterday I have written a first draft of a best practices process for how we should try to use JIRA/svn to track bugs:

https://wiki.opendnssec.org/display/OpenDNSSEC/Bug+tracking+process

Please review this and let me know what you think! I'll make sure to raise it in the next team meeting for discussion too. 

Thanks.

Sara.



From rick at openfortress.nl  Tue Dec  4 16:29:13 2012
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 4 Dec 2012 16:29:13 +0000
Subject: [Opendnssec-develop] Re: Access to OpenDNSSEC Wiki
In-Reply-To: <E038B942-504E-458C-B2F9-FB3780568427@sinodun.com>
References: <50BCAF4A.1060706@uvt.nl>
	<E038B942-504E-458C-B2F9-FB3780568427@sinodun.com>
Message-ID: <20121204162913.GC9357@newphantom.local>

Hi Sara,

	Wonderful, thanks!

And Casper,

	I dare you to prod around ;-)

Cheers,
 -Rick


From rick at openfortress.nl  Wed Dec  5 10:40:57 2012
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 5 Dec 2012 10:40:57 +0000
Subject: [Opendnssec-develop] Meeting notes 2012-12-03
Message-ID: <20121205104057.GA12855@newphantom.local>

Hello all,

The meeting notes of our 2012-12-03 "meeting" are now online,
and I hope you will find that they are fine:

https://wiki.opendnssec.org/display/OpenDNSSEC/2012-12-03+Minutes

My notes were not 100% conclusive on the 1.4.0 actions by Sion and Matthijs
So if someone could have a look at those, that would be nice.


Cheers,
 -Rick


PS: Today is our country's Sinterklaas tradition,
    and mailing in rhyme then is then OpenFortress's mission.


From sara at sinodun.com  Thu Dec  6 10:43:51 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Dec 2012 10:43:51 +0000
Subject: [Opendnssec-develop] Meeting notes 2012-12-03
In-Reply-To: <20121205104057.GA12855@newphantom.local>
References: <20121205104057.GA12855@newphantom.local>
Message-ID: <0FFD4DD8-4D96-4D54-ADBA-BE454524B7B3@sinodun.com>


On 5 Dec 2012, at 10:40, Rick van Rein wrote:

> Hello all,
> 
> The meeting notes of our 2012-12-03 "meeting" are now online,
> and I hope you will find that they are fine:
> 
> https://wiki.opendnssec.org/display/OpenDNSSEC/2012-12-03+Minutes
> 
> My notes were not 100% conclusive on the 1.4.0 actions by Sion and Matthijs
> So if someone could have a look at those, that would be nice.

Thanks Rick - I have added a couple of comments from my recollection of the meeting for other to double check. 

Sara.

> 
> 
> Cheers,
> -Rick
> 
> 
> PS: Today is our country's Sinterklaas tradition,
>    and mailing in rhyme then is then OpenFortress's mission.
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop



From sara at sinodun.com  Thu Dec  6 10:56:36 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Dec 2012 10:56:36 +0000
Subject: [Opendnssec-develop] RE: On leave for a few days next week
Message-ID: <611C00E9-3FEE-4214-B298-75BE34C253C2@sinodun.com>

Hi All, 

Sorry for the short notice but I am going to be on leave Monday afternoon, Tuesday and Wednesday next week with probably no access to email. Back Thursday.

Sara.



From matthijs at nlnetlabs.nl  Thu Dec  6 12:28:48 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 06 Dec 2012 13:28:48 +0100
Subject: [Opendnssec-develop] Meeting notes 2012-12-03
In-Reply-To: <20121205104057.GA12855@newphantom.local>
References: <20121205104057.GA12855@newphantom.local>
Message-ID: <50C08F80.7070701@nlnetlabs.nl>

On 12/05/2012 11:40 AM, Rick van Rein wrote:
> Hello all,
>
> The meeting notes of our 2012-12-03 "meeting" are now online,
> and I hope you will find that they are fine:
>
> https://wiki.opendnssec.org/display/OpenDNSSEC/2012-12-03+Minutes
>
> My notes were not 100% conclusive on the 1.4.0 actions by Sion and Matthijs
> So if someone could have a look at those, that would be nice.
>
>
> Cheers,
>   -Rick
>
>
> PS: Today is our country's Sinterklaas tradition,
>      and mailing in rhyme then is then OpenFortress's mission.

The notes look fine to me, and if it wasn't for that PS, I didn't notice 
you were rhyming ;)

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



From matthijs at nlnetlabs.nl  Thu Dec  6 12:42:29 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 06 Dec 2012 13:42:29 +0100
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
Message-ID: <50C092B5.5000704@nlnetlabs.nl>

On 11/26/2012 04:03 PM, Sara Dickinson wrote:
> Hi All,
>
> So I have been having another look lately at the regression tests and
> how we could manage them better as we add more tests. (They are
> currently a mixture of imported scripts with a numeric naming
> convention and new tests added by us.) My plan is to do the following
> things:
>
> - come up with a new naming convention for the test scripts - come up
> with a way to track what is currently tested (including bug fixes) -
> review which tests should be smoke/daily/weekly - re-vamp the Test
> Coverage wiki page to more clearly see what tests still need adding
>
> I've had a go at the first two so am looking for some feedback before
> moving any further.... More details on both the following suggestions
> are on the wiki page:
> https://wiki.opendnssec.org/display/OpenDNSSEC/Test+case+policy
>
> Naming ------------- My idea for naming is to split the names into 3
> parts (based on the area tested - see the wiki). These parts would be
> separated by dashes, with word separated by underscores within the 3
> parts. So for example we might have:
>
> enforcer-keys-check_backup_required_works
> signer-adaptors-many_dns_updates general-repository-opendnssecXXX

I like the idea of structuring tests, although I think those names may 
become quite long, especially later if we have to test weird, specific 
corner cases. 
(signer-adapters-many_dns_updates_all_ixfr_over_udp_and_some_packets_are_dropped)

Perhaps signer-adapters-XXXX where XXXX is just a number?

> I thought this was easier than using than a numbering system and
> since we currently run all the tests regardless of any failures then
> the ordering within the directory doesn't really matter (at the
> moment anyway). We could alternatively use a directory structure
> along these lines but I'm not convinced that having to always drill
> down further to the test scripts ultimately makes life easier...?
> Please let me know if you can think of improvements or alternatives
> to this.
>
> Tracking ------------- On the tracking side of things I took the
> approach that the most reliable way to track things is to have a way
> to grab information directly from the tests rather than try to have a
> separate document that needs updating and so is likely to get out of
> date. I have written a small script that grabs info from the comments
> in the test scripts and generates a CSV file as output. It needs more
> work and really should be incorporated into the framework if we
> decide to adopt this approach - at the moment it is just to generate
> feedback. An example excel spreadsheet generated from the information
> extracted (including new suggested names for the existing tests) is
> attached to the wiki page for people to review.
>
> This does rely on the comments in the tests being accurate and up to
> date but that seems a good idea anyway!  Please try this out and let
> me know if you think this approach makes sense.

I like this idea. I think the comments are mainly useful for tracking 
which JIRA issue is tested (which I know aren't many now).

Best regards,
   Matthijs

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



From sara at sinodun.com  Thu Dec  6 13:16:01 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Dec 2012 13:16:01 +0000
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <50C092B5.5000704@nlnetlabs.nl>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
Message-ID: <4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>


On 6 Dec 2012, at 12:42, Matthijs Mekking wrote:
> 
> I like the idea of structuring tests, although I think those names may become quite long, especially later if we have to test weird, specific corner cases. (signer-adapters-many_dns_updates_all_ixfr_over_udp_and_some_packets_are_dropped)

Point taken...I guess I has assumed we would stick to 2 or 3 words...

> 
> Perhaps signer-adapters-XXXX where XXXX is just a number?

You are right - numbers would help. What about 3 words and a number:

signer-adapters-bind-XXX
signer-zones-validation-XXX
enforcer-keys-backup-XXX
enforcer-keys-rollover-XXX

>> 
>> This does rely on the comments in the tests being accurate and up to
>> date but that seems a good idea anyway!  Please try this out and let
>> me know if you think this approach makes sense.
> 
> I like this idea. I think the comments are mainly useful for tracking which JIRA issue is tested (which I know aren't many now).

Thanks for the feedback.

Sara.

> 
> Best regards,
>  Matthijs
> 



From sara at sinodun.com  Thu Dec  6 13:44:41 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Dec 2012 13:44:41 +0000
Subject: [Opendnssec-develop] RE: 1.4.0b2 release
Message-ID: <1AC8CEF2-0699-43E9-853A-69DB4BBB874F@sinodun.com>

Hi, 

So since I'm away at the beginning of next week I'm wondering if we can get the beta 2 release out by the end of this week? 

Sion - I saw you did one update on the valgrind stuff - is that everything?

Matthijs - looking at the jenkins tests on trunk there are some failures. I just re-ran all the tests to see if was an intermittent failure but some are still red. Could you please take a look at this? I don't want to release if any tests are failing and right now I don't know if this is understood or not? 

Matthijs - I also looked in the NEWS file and saw an entry "* Allow multiple KSKs." I'm not sure what this means....? Could you add a little more detail please  :-)

Let me know asap if there is anything else needed before the release. 

Thanks!

Sara.

From sion at nominet.org.uk  Thu Dec  6 13:53:15 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 6 Dec 2012 13:53:15 +0000
Subject: [Opendnssec-develop] RE: 1.4.0b2 release
In-Reply-To: <1AC8CEF2-0699-43E9-853A-69DB4BBB874F@sinodun.com>
References: <1AC8CEF2-0699-43E9-853A-69DB4BBB874F@sinodun.com>
Message-ID: <50C0A34B.3090704@nominet.org.uk>

On 06/12/12 13:44, Sara Dickinson wrote:
> Hi, 
>
> So since I'm away at the beginning of next week I'm wondering if we can get the beta 2 release out by the end of this week? 
>
> Sion - I saw you did one update on the valgrind stuff - is that everything?

I think so; although I'm not sure exactly what jerry ran to see those
issues so I may have missed some.

Sion


From sara at sinodun.com  Thu Dec  6 14:10:44 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Dec 2012 14:10:44 +0000
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
	<4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
Message-ID: <D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>

Hi, 

Also on this topic I have another suggestion.... 

When we make svn commits that are purely regression test related, how about we use the following format for the update:

TEST: Add new method called blah to test framework.
TEST (enforcer-keys-backup-1): Add new test script to cover.....

In other words in the same way we use OPENDNSSEC/SUPPORT as identifiers for bug fixes we use TEST to show the update is purely test related (a specific test name is a nice to have). It will make life (well, my life for sure :-) ) much easier when looking through lots of subversion updates to be able to ignore things that haven't affected the functionality of the product. 

WDYT?

Sara.

From sion at nominet.org.uk  Thu Dec  6 14:16:34 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 6 Dec 2012 14:16:34 +0000
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
	<4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
	<D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>
Message-ID: <50C0A8C2.30809@nominet.org.uk>

On 06/12/12 14:10, Sara Dickinson wrote:
> Hi, 
>
> Also on this topic I have another suggestion.... 
>
> When we make svn commits that are purely regression test related, how about we use the following format for the update:
>
> TEST: Add new method called blah to test framework.
> TEST (enforcer-keys-backup-1): Add new test script to cover.....
>
> In other words in the same way we use OPENDNSSEC/SUPPORT as identifiers for bug fixes we use TEST to show the update is purely test related (a specific test name is a nice to have). It will make life (well, my life for sure :-) ) much easier when looking through lots of subversion updates to be able to ignore things that haven't affected the functionality of the product. 
>
> WDYT?
>
>

Works for me. We'd have to commit tests and functionality in separate
revisions, but I don't see that being an issue.

Sion


From sara at sinodun.com  Thu Dec  6 14:29:29 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Dec 2012 14:29:29 +0000
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <50C0A8C2.30809@nominet.org.uk>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
	<4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
	<D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>
	<50C0A8C2.30809@nominet.org.uk>
Message-ID: <451748CD-4B92-45E6-A9AC-8648E8661E97@sinodun.com>


On 6 Dec 2012, at 14:16, Si?n Lloyd wrote:

> On 06/12/12 14:10, Sara Dickinson wrote:
>> Hi, 
>> 
>> Also on this topic I have another suggestion.... 
>> 
>> When we make svn commits that are purely regression test related, how about we use the following format for the update:
>> 
>> TEST: Add new method called blah to test framework.
>> TEST (enforcer-keys-backup-1): Add new test script to cover.....
>> 
>> In other words in the same way we use OPENDNSSEC/SUPPORT as identifiers for bug fixes we use TEST to show the update is purely test related (a specific test name is a nice to have). It will make life (well, my life for sure :-) ) much easier when looking through lots of subversion updates to be able to ignore things that haven't affected the functionality of the product. 
>> 
>> WDYT?
>> 
>> 
> 
> Works for me. We'd have to commit tests and functionality in separate
> revisions, but I don't see that being an issue.
> 

Good point - but that does seem to be how most people work at the moment.... And could always do:

SUPPORT-XX & TEST: Fix bug and update regression test

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



From matthijs at nlnetlabs.nl  Thu Dec  6 14:54:25 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Thu, 06 Dec 2012 15:54:25 +0100
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <451748CD-4B92-45E6-A9AC-8648E8661E97@sinodun.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
	<4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
	<D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>
	<50C0A8C2.30809@nominet.org.uk>
	<451748CD-4B92-45E6-A9AC-8648E8661E97@sinodun.com>
Message-ID: <50C0B1A1.7050801@nlnetlabs.nl>

On 12/06/2012 03:29 PM, Sara Dickinson wrote:
>
> On 6 Dec 2012, at 14:16, Si?n Lloyd wrote:
>
>> On 06/12/12 14:10, Sara Dickinson wrote:
>>> Hi,
>>>
>>> Also on this topic I have another suggestion....
>>>
>>> When we make svn commits that are purely regression test related, how about we use the following format for the update:
>>>
>>> TEST: Add new method called blah to test framework.
>>> TEST (enforcer-keys-backup-1): Add new test script to cover.....
>>>
>>> In other words in the same way we use OPENDNSSEC/SUPPORT as identifiers for bug fixes we use TEST to show the update is purely test related (a specific test name is a nice to have). It will make life (well, my life for sure :-) ) much easier when looking through lots of subversion updates to be able to ignore things that haven't affected the functionality of the product.
>>>
>>> WDYT?
>>>
>>>
>>
>> Works for me. We'd have to commit tests and functionality in separate
>> revisions, but I don't see that being an issue.
>>
>
> Good point - but that does seem to be how most people work at the moment.... And could always do:
>
> SUPPORT-XX & TEST: Fix bug and update regression test

Yes, but (nit warning) I would prefer

SUPPORT-XX

TEST: Fix bug

(separated by newlines)

>
>> Sion
>> _______________________________________________
>> 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 sara at sinodun.com  Thu Dec  6 16:58:06 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 6 Dec 2012 16:58:06 +0000
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <50C0B1A1.7050801@nlnetlabs.nl>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
	<4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
	<D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>
	<50C0A8C2.30809@nominet.org.uk>
	<451748CD-4B92-45E6-A9AC-8648E8661E97@sinodun.com>
	<50C0B1A1.7050801@nlnetlabs.nl>
Message-ID: <47550CE0-E72A-4606-9FB2-E2EA3E820E3E@sinodun.com>


On 6 Dec 2012, at 14:54, Matthijs Mekking wrote:
>>> Good point - but that does seem to be how most people work at the moment.... And could always do:
>> 
>> SUPPORT-XX & TEST: Fix bug and update regression test
> 
> Yes, but (nit warning) I would prefer
> 
> SUPPORT-XX
> 
> TEST: Fix bug
> 
> (separated by newlines)

(Nit-tastic warning) Wouldn't:

SUPPORT-XX: Fix bug where.....
TEST: Added regression test X-Y-Z-01 to cover this scenario

be even better if you are doing both in one return? However, my main motivation was to make it easy to filter out updates that ONLY affected regression tests so I'm not that bothered. And this is mainly useful when I am looking for possibly important updates that went in without an issue number :-)

We could come up with a whole range of identifiers (BUG: BUILD: RELEASE:) if people thought it was useful?

Sara.



From jerry at opendnssec.org  Mon Dec 10 07:55:41 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 10 Dec 2012 08:55:41 +0100
Subject: [Opendnssec-develop] RE: 1.3.12 release candidate
In-Reply-To: <624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>
References: <F168587B-17DC-4962-BA43-036F349B9685@sinodun.com>
	<624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>
Message-ID: <CAGTFMNZeFaMoJPf-2sso-MLbR7YF4gzqyAb5N+skbroqc7vAYQ@mail.gmail.com>

Hi,

On Mon, Nov 26, 2012 at 3:05 PM, Sara Dickinson <sara at sinodun.com> wrote:
> Since we have a release candidate issued please refrain from submitting routine code into the 1.3.12 branch until the full release is done. If you have a high priority issue that you believe warrants the re-issue of the release candidate please email the developers list first so this can be agreed.

It isn't necessary to "lock" the branch while a release candidate is issued.

You can copy the release candidate tag once it is decided to release
the full version and if any change had been made that should be
included in the release you can merge it with the release tag after
copy.

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


From jerry at opendnssec.org  Mon Dec 10 08:10:50 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 10 Dec 2012 09:10:50 +0100
Subject: [Opendnssec-develop] Re: [Opendnssec-user]How to speed up signing
	performance
In-Reply-To: <50ACF46B.7080006@nlnetlabs.nl>
References: <201208311414234414091125@126.com>
	<alpine.LFD.2.02.1208311257080.17923@bofh.nohats.ca>
	<CAGTFMNZPArySPxoR7Uh8MepdULZCsuhTrfYD5UCEf6r1DytL8g@mail.gmail.com>
	<alpine.LFD.2.02.1209051654270.20204@bofh.nohats.ca>
	<50ACF46B.7080006@nlnetlabs.nl>
Message-ID: <CAGTFMNZ4+OfNNBCg90k4eF8sFPsfsJD778cXEmt1eK0sUi4HQQ@mail.gmail.com>

Hi,

On Wed, Nov 21, 2012 at 4:34 PM, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
> The cpu patch was incorporated and is already included in the 1.4 beta.
>
> The aggressive retry patch is also applied, with small adjustments:
>
> -        if (status == ODS_STATUS_UNCHANGED) {
> -            worker_wait_timeout_locked(&q->q_lock, &q->q_nonfull, 60);
> +        if (!tries && status == ODS_STATUS_UNCHANGED) {
> +            worker_wait_timeout_locked(&q->q_lock, &q->q_nonfull, 5);
>          }
>
> The waiting should only occur when the number of max tries has been
> reached (tries has been reset to 0). Also, 60 seconds seems indeed a
> long maximum wait, 5 will do too (If the queue is not full, the timeout
> should of course be shorter). This change is for now only in trunk, it
> will be in the 1.4 rc.

I feel that the assumption that 60 seconds is a long time to wait is false.

If the locking/condition/signal code for the workers was working then
you could actually wait forever because it would be signaled when
there is more work.

Seeing that this patch has been introduced then it means that that
code does not work as it should and it could lead to more problems
like dead locks / slow downs and CPU hogging.

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


From jerry at opendnssec.org  Mon Dec 10 08:13:43 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 10 Dec 2012 09:13:43 +0100
Subject: [Opendnssec-develop] RE: 1.4.0b2 release
In-Reply-To: <50C0A34B.3090704@nominet.org.uk>
References: <1AC8CEF2-0699-43E9-853A-69DB4BBB874F@sinodun.com>
	<50C0A34B.3090704@nominet.org.uk>
Message-ID: <CAGTFMNbOY3b8dugNdW8FDzFFCFWoywX6QavinFfDtB0zgL24nQ@mail.gmail.com>

On Thu, Dec 6, 2012 at 2:53 PM, Si?n Lloyd <sion at nominet.org.uk> wrote:
> I think so; although I'm not sure exactly what jerry ran to see those
> issues so I may have missed some.

Just valgrind when debugging another problem.

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


From matthijs at nlnetlabs.nl  Mon Dec 10 10:00:52 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 10 Dec 2012 11:00:52 +0100
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <47550CE0-E72A-4606-9FB2-E2EA3E820E3E@sinodun.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
	<4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
	<D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>
	<50C0A8C2.30809@nominet.org.uk>
	<451748CD-4B92-45E6-A9AC-8648E8661E97@sinodun.com>
	<50C0B1A1.7050801@nlnetlabs.nl>
	<47550CE0-E72A-4606-9FB2-E2EA3E820E3E@sinodun.com>
Message-ID: <50C5B2D4.20803@nlnetlabs.nl>

On 12/06/2012 05:58 PM, Sara Dickinson wrote:
> 
> On 6 Dec 2012, at 14:54, Matthijs Mekking wrote:
>>>> Good point - but that does seem to be how most people work at the moment.... And could always do:
>>>
>>> SUPPORT-XX & TEST: Fix bug and update regression test
>>
>> Yes, but (nit warning) I would prefer
>>
>> SUPPORT-XX
>>
>> TEST: Fix bug
>>
>> (separated by newlines)
> 
> (Nit-tastic warning) Wouldn't:

I asked for it, didn't I? :)

> 
> SUPPORT-XX: Fix bug where.....
> TEST: Added regression test X-Y-Z-01 to cover this scenario
> 
> be even better if you are doing both in one return? However, my main motivation was to make it easy to filter out updates that ONLY affected regression tests so I'm not that bothered. And this is mainly useful when I am looking for possibly important updates that went in without an issue number :-)

My motivation is one update per line for readability.

> 
> We could come up with a whole range of identifiers (BUG: BUILD: RELEASE:) if people thought it was useful?

Let's not overengineer. For me, SUPPORT/OPENDNSSEC/TEST are sufficient
for now.

Best regards,
  Matthijs


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121210/6ad13257/attachment.bin>

From matthijs at nlnetlabs.nl  Mon Dec 10 10:11:28 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 10 Dec 2012 11:11:28 +0100
Subject: [Opendnssec-develop] RE: Process for tracking bugs
In-Reply-To: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
References: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
Message-ID: <50C5B550.4050202@nlnetlabs.nl>

Hi,

The first part lists stuff that I already (try to) do when working on a
JIRA issue. So I approve with this.

The second part is more interesting. I have a hard time to decide
whether something needs go into JIRA. For example, if there is a report
on the mailing list, should we create a JIRA issue for it? According to
your text, only if it results in code changes. I can see another option:
Always, even if the report turns out to be an error outside  OpenDNSSEC,
or a not accepted feature request. This way, we can refer to them when
similar future reports come in.

Also, I sometimes change log levels for log messages, as I feel that the
daemon is too verbose, or not verbose enough. These are code changes,
but I don't think a JIRA report is needed for them.

Best regards,
  Matthijs



On 12/04/2012 04:40 PM, Sara Dickinson wrote:
> Hi All, 
> 
> As a follow up to the team meeting yesterday I have written a first draft of a best practices process for how we should try to use JIRA/svn to track bugs:
> 
> https://wiki.opendnssec.org/display/OpenDNSSEC/Bug+tracking+process
> 
> Please review this and let me know what you think! I'll make sure to raise it in the next team meeting for discussion too. 
> 
> Thanks.
> 
> Sara.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121210/8ab08990/attachment.bin>

From jerry at opendnssec.org  Mon Dec 10 10:36:41 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 10 Dec 2012 11:36:41 +0100
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <50C5B2D4.20803@nlnetlabs.nl>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<50C092B5.5000704@nlnetlabs.nl>
	<4708D903-152A-415E-B1B2-538584CBB349@sinodun.com>
	<D6F3F802-0083-448B-9147-11053C4440CB@sinodun.com>
	<50C0A8C2.30809@nominet.org.uk>
	<451748CD-4B92-45E6-A9AC-8648E8661E97@sinodun.com>
	<50C0B1A1.7050801@nlnetlabs.nl>
	<47550CE0-E72A-4606-9FB2-E2EA3E820E3E@sinodun.com>
	<50C5B2D4.20803@nlnetlabs.nl>
Message-ID: <CAGTFMNbL9yNi4KG0w0n14aO+FBiF7mGC7kmLwQQPHsgivonvYQ@mail.gmail.com>

On Mon, Dec 10, 2012 at 11:00 AM, Matthijs Mekking
<matthijs at nlnetlabs.nl> wrote:
> Let's not overengineer.

+1

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


From sara at sinodun.com  Mon Dec 10 10:38:46 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 10 Dec 2012 10:38:46 +0000
Subject: [Opendnssec-develop] RE: 1.3.12 release candidate
In-Reply-To: <CAGTFMNZeFaMoJPf-2sso-MLbR7YF4gzqyAb5N+skbroqc7vAYQ@mail.gmail.com>
References: <F168587B-17DC-4962-BA43-036F349B9685@sinodun.com>
	<624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>
	<CAGTFMNZeFaMoJPf-2sso-MLbR7YF4gzqyAb5N+skbroqc7vAYQ@mail.gmail.com>
Message-ID: <6079AF48-DF6C-4617-8AFB-083EAA3B8228@sinodun.com>

Hi Jerry, 

It is a good point that it isn't necessary but based on discussions in the team meetings and the fact it has been documented as part of the process for some time now I took this as what we had agreed to do.

We could alternatively do as suggested below however I would not vote in favour of this. I prefer freezing the branch as it is a much simpler approach and is less error prone than having to merge changes. I would suggest we continue with the current process and if we do find it to be an issue then we could review things. However if others feel differently then please speak up! 

Sara.

On 10 Dec 2012, at 07:55, Jerry Lundstr?m wrote:

> Hi,
> 
> On Mon, Nov 26, 2012 at 3:05 PM, Sara Dickinson <sara at sinodun.com> wrote:
>> Since we have a release candidate issued please refrain from submitting routine code into the 1.3.12 branch until the full release is done. If you have a high priority issue that you believe warrants the re-issue of the release candidate please email the developers list first so this can be agreed.
> 
> It isn't necessary to "lock" the branch while a release candidate is issued.
> 
> You can copy the release candidate tag once it is decided to release
> the full version and if any change had been made that should be
> included in the release you can merge it with the release tag after
> copy.
> 
> -- 
> Jerry Lundstr?m - OpenDNSSEC Developer
> http://www.opendnssec.org/



From matthijs at nlnetlabs.nl  Mon Dec 10 10:41:29 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 10 Dec 2012 11:41:29 +0100
Subject: [Opendnssec-develop] RE: 1.3.12 release candidate
In-Reply-To: <6079AF48-DF6C-4617-8AFB-083EAA3B8228@sinodun.com>
References: <F168587B-17DC-4962-BA43-036F349B9685@sinodun.com>
	<624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>
	<CAGTFMNZeFaMoJPf-2sso-MLbR7YF4gzqyAb5N+skbroqc7vAYQ@mail.gmail.com>
	<6079AF48-DF6C-4617-8AFB-083EAA3B8228@sinodun.com>
Message-ID: <50C5BC59.2020002@nlnetlabs.nl>

We could also 'tag' the release candidate. Tagging means making no
changes to them. If changes are required, they are made in the branch.
If changes are made, a new rc is created from branch. Advantages: No
need for merging and no need to freeze the branch.

Best regards,
  Matthijs

On 12/10/2012 11:38 AM, Sara Dickinson wrote:
> Hi Jerry, 
> 
> It is a good point that it isn't necessary but based on discussions in the team meetings and the fact it has been documented as part of the process for some time now I took this as what we had agreed to do.
> 
> We could alternatively do as suggested below however I would not vote in favour of this. I prefer freezing the branch as it is a much simpler approach and is less error prone than having to merge changes. I would suggest we continue with the current process and if we do find it to be an issue then we could review things. However if others feel differently then please speak up! 
> 
> Sara.
> 
> On 10 Dec 2012, at 07:55, Jerry Lundstr?m wrote:
> 
>> Hi,
>>
>> On Mon, Nov 26, 2012 at 3:05 PM, Sara Dickinson <sara at sinodun.com> wrote:
>>> Since we have a release candidate issued please refrain from submitting routine code into the 1.3.12 branch until the full release is done. If you have a high priority issue that you believe warrants the re-issue of the release candidate please email the developers list first so this can be agreed.
>>
>> It isn't necessary to "lock" the branch while a release candidate is issued.
>>
>> You can copy the release candidate tag once it is decided to release
>> the full version and if any change had been made that should be
>> included in the release you can merge it with the release tag after
>> copy.
>>
>> -- 
>> Jerry Lundstr?m - OpenDNSSEC Developer
>> http://www.opendnssec.org/
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121210/1527d580/attachment.bin>

From sara at sinodun.com  Mon Dec 10 12:02:21 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 10 Dec 2012 12:02:21 +0000
Subject: [Opendnssec-develop] RE: Process for tracking bugs
In-Reply-To: <50C5B550.4050202@nlnetlabs.nl>
References: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
	<50C5B550.4050202@nlnetlabs.nl>
Message-ID: <EA99E286-EEC7-467D-9798-2ECFAE8939AE@sinodun.com>

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


On 10 Dec 2012, at 10:11, Matthijs Mekking wrote:

> Hi,
> 
> The first part lists stuff that I already (try to) do when working on a
> JIRA issue. So I approve with this.
> 
> The second part is more interesting. I have a hard time to decide
> whether something needs go into JIRA.

Thanks for the feedback Matthijs.

One thing that I think we do need to resolve is the question of where to look to see what has changed since the last release and what is still outstanding (for us and to be able to report to users). Right now when we have team meetings and try to decide if we should do a release we currently only look at JIRA. So if there are other important updates that are only in the NEWS file (or only in svn or on the mailing list) then we don't take them into account. 

So we could look at both but.. if something is only in the NEWS file then I assume it means it is fixed (but I don't know what revision it was fixed in), and I don't know if it has been manually tested / covered in jenkins / documented / etc? All useful stuff which could/should go in a JIRA issue.

What I am suggesting is that if changes the behaviour of OpenDNSSEC or fixes a bug then it should go in the NEWS file (this pretty much happens already). And if it is important enough to go in the NEWS file then it should go in JIRA too. 


> For example, if there is a report
> on the mailing list, should we create a JIRA issue for it? According to
> your text, only if it results in code changes.

I really meant _always_ open an issue if it results in code changes (for the reasons above) but this doesn't mean we shouldn't open issues for other things. I can clarify this in the text. 

> I can see another option:
> Always, even if the report turns out to be an error outside  OpenDNSSEC,
> or a not accepted feature request. This way, we can refer to them when
> similar future reports come in.

I don't know that it is useful to mandate we always open an issue but it seems good practice to track important ones in JIRA. 
Feature requests - I think we should always open an issue so it can be reviewed properly
User errors - don't think a JIRA issue is that helpful.
Common misunderstanding - maybe better to add to the FAQ?

> 
> Also, I sometimes change log levels for log messages, as I feel that the
> daemon is too verbose, or not verbose enough. These are code changes,
> but I don't think a JIRA report is needed for them.

I think a bit of common sense can be used here e.g. if you change the format or text of a common log message that users (or our tests) may grep for then let people know by raising an issue, but the kind of tweaks you mention wouldn't need one. 

Sara.

> 
> Best regards,
>  Matthijs
> 
> 
> 
> On 12/04/2012 04:40 PM, Sara Dickinson wrote:
>> Hi All, 
>> 
>> As a follow up to the team meeting yesterday I have written a first draft of a best practices process for how we should try to use JIRA/svn to track bugs:
>> 
>> https://wiki.opendnssec.org/display/OpenDNSSEC/Bug+tracking+process
>> 
>> Please review this and let me know what you think! I'll make sure to raise it in the next team meeting for discussion too. 
>> 
>> Thanks.
>> 
>> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQxc9RAAoJEAuxXeCvTgIIdk8H/A8fnkSPqgPk3Yal4N3gvvhY
IBhkTUb6pGSGNaqyfDKc5B7FmHwQe62mehffe+MEGPbYCRN/+4YmcRglAdXVWKWW
2no3Ol418kw42fquuZmCCCW6NhfYMptNaA+EPrdH9YcykCHdbBes4+//XQz3wPhU
H5qtHuo1C3RIRnD0xwATey1lsJ4wljbJTv6yh72wIPRdLMx0z1Rqhb3nb0kbGUWJ
Hs1n3glPxLQurmx54WnB5YQoKr8gIH7Zq0zm/IC0dZf8LqzGm7MW0DzcIh72W/bz
qtLIFVTcI/ASQ2t0XNyQIrk+yW2ebXdqQGTNvwn7TnmtkxB3B5eEdNYK9JOc2JA=
=QI05
-----END PGP SIGNATURE-----


From jerry at opendnssec.org  Tue Dec 11 08:51:17 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 11 Dec 2012 09:51:17 +0100
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
Message-ID: <CAGTFMNZ6ig6LF9nAXJR1WD=HzZ=cRY2kso9X68F-sc0UtK1DOQ@mail.gmail.com>

Hi,

On Mon, Nov 26, 2012 at 4:03 PM, Sara Dickinson <sara at sinodun.com> wrote:
> I've had a go at the first two so am looking for some feedback before moving any further.... More details on both the following suggestions are on the wiki page: https://wiki.opendnssec.org/display/OpenDNSSEC/Test+case+policy

Policy looks good.

> Naming

What ever we agree on is fine by me as long as we all use the same.

> Tracking

This is fine as long as it does not make the test case directories in
each branch the "master database" of what is to be tested. In other
words; I would rather have the wiki as a master saying what kinds of
tests we should have and then maybe auto generate tests into each
branch then adding the test code for that branch for those specific
cases.

Also, could we move that script out from the OpenDNSSEC trunk branch
into maybe trunk/testing ?

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


From jerry at opendnssec.org  Tue Dec 11 09:02:46 2012
From: jerry at opendnssec.org (=?ISO-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 11 Dec 2012 10:02:46 +0100
Subject: [Opendnssec-develop] RE: Process for tracking bugs
In-Reply-To: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
References: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
Message-ID: <CAGTFMNYBgfutGFiO6qo5n4z2+fDoGy+6o4i+PPRY4S9z-s=h3g@mail.gmail.com>

Hi,

On Tue, Dec 4, 2012 at 4:40 PM, Sara Dickinson <sara at sinodun.com> wrote:
> https://wiki.opendnssec.org/display/OpenDNSSEC/Bug+tracking+process

Looks good, I just have two comment:

"Resolve - Add a comment to the issue with the svn revision(s) (or
even better, a fisheye link to the revision)."

This is not be necessary if you tagged the commit correctly, it will
show up in the JIRA issue if you select All or Source tab (which is
why we have FishEye after all).

"Resolve - Clearly state what branches have been fixed."

This can be simplified if we start using different issues for
different branches/versions, for example if a problem might be related
to 2 or more branches/versions you make an issue about the problem
then create subtasks / linked issues for each related branch/version.

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


From sion at nominet.org.uk  Tue Dec 11 11:09:23 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Tue, 11 Dec 2012 11:09:23 +0000
Subject: [Opendnssec-develop] Meeting on the 18th
Message-ID: <50C71463.8000204@nominet.org.uk>

I won't be able to make the meeting that we have scheduled for the 18th.

Could we move it a day either way?

Cheers,

Sion


From yuri at nlnetlabs.nl  Tue Dec 11 11:26:46 2012
From: yuri at nlnetlabs.nl (Yuri Schaeffer)
Date: Tue, 11 Dec 2012 12:26:46 +0100
Subject: [Opendnssec-develop] Meeting on the 18th
In-Reply-To: <50C71463.8000204@nominet.org.uk>
References: <50C71463.8000204@nominet.org.uk>
Message-ID: <50C71876.4040002@nlnetlabs.nl>

> I won't be able to make the meeting that we have scheduled for the 18th.
> Could we move it a day either way?

17th would work and 19 would not work for me.


From matthijs at nlnetlabs.nl  Tue Dec 11 11:31:12 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Tue, 11 Dec 2012 12:31:12 +0100
Subject: [Opendnssec-develop] Meeting on the 18th
In-Reply-To: <50C71876.4040002@nlnetlabs.nl>
References: <50C71463.8000204@nominet.org.uk> <50C71876.4040002@nlnetlabs.nl>
Message-ID: <50C71980.5000603@nlnetlabs.nl>

Same here

On 12/11/2012 12:26 PM, Yuri Schaeffer wrote:
>> I won't be able to make the meeting that we have scheduled for the 18th.
>> Could we move it a day either way?
> 
> 17th would work and 19 would not work for me.
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121211/026141d6/attachment.bin>

From matthijs at nlnetlabs.nl  Tue Dec 11 13:42:08 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Tue, 11 Dec 2012 14:42:08 +0100
Subject: [Opendnssec-develop] RE: 1.4.0b2 release
In-Reply-To: <1AC8CEF2-0699-43E9-853A-69DB4BBB874F@sinodun.com>
References: <1AC8CEF2-0699-43E9-853A-69DB4BBB874F@sinodun.com>
Message-ID: <50C73830.3070104@nlnetlabs.nl>

On 12/06/2012 02:44 PM, Sara Dickinson wrote:
> Hi, 
> 
> So since I'm away at the beginning of next week I'm wondering if we can get the beta 2 release out by the end of this week? 
> 
> Sion - I saw you did one update on the valgrind stuff - is that everything?
> 
> Matthijs - looking at the jenkins tests on trunk there are some failures. I just re-ran all the tests to see if was an intermittent failure but some are still red. Could you please take a look at this? I don't want to release if any tests are failing and right now I don't know if this is understood or not? 

I think these now have been fixed, thanks to commit r6887.

http://fisheye.opendnssec.org/changelog/opendnssec?cs=6887

> Matthijs - I also looked in the NEWS file and saw an entry "* Allow multiple KSKs." I'm not sure what this means....? Could you add a little more detail please  :-)

I think this was for the enforcer NG, to support all kinds of rollovers.
I think it shouldn't be in the NEWS file anyway and I removed it.

Best regards,
  Matthijs


> 
> Let me know asap if there is anything else needed before the release. 
> 
> Thanks!
> 
> Sara._______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121211/a64a0cbc/attachment.bin>

From jerry at opendnssec.org  Tue Dec 11 15:14:01 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 11 Dec 2012 16:14:01 +0100
Subject: [Opendnssec-develop] Server at SURFnet for large tests is up but no
	network (titan.buildfarm.opendnssec.org)
Message-ID: <6A76F8E0-1170-4AC8-863E-36AA7D02513E@opendnssec.org>

Hi,

As subject, its up and installed but I have not gotten the network details so it can't be reached yet.

/Jerry

--
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/20121211/8c21bbc8/attachment.bin>

From jerry at opendnssec.org  Tue Dec 11 15:19:06 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 11 Dec 2012 16:19:06 +0100
Subject: [Opendnssec-develop] Meeting notes 2012-12-03
In-Reply-To: <20121205104057.GA12855@newphantom.local>
References: <20121205104057.GA12855@newphantom.local>
Message-ID: <9CA5B06C-4F7E-484C-A727-1BA876FEF1D3@opendnssec.org>

Hi,

On Dec 5, 2012, at 11:40 , Rick van Rein wrote:

> https://wiki.opendnssec.org/display/OpenDNSSEC/2012-12-03+Minutes


From notes:

Matthijs	OPENDNSSEC-346: BIND interop test
The test is written and submitted to svn so we now need to have BIND installed on at least one test machine. We agree this needs to wait till Jerry is back next week. We also agree that starting with the CentOS machine seems like the right thing.


I will installed bind on redhat64-ods08, the CentOS server is to be converted into 32bit Red Hat.

There is currently no way to just run a test on a single platform so the test needs to run on all platforms and it could do a case on $DISTRIBUTION (as in most build-*.sh) to only do the test on redhat and return 0 on all other platforms.

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



From jerry at opendnssec.org  Tue Dec 11 15:25:03 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 11 Dec 2012 16:25:03 +0100
Subject: [Opendnssec-develop] Meeting notes 2012-12-03
In-Reply-To: <9CA5B06C-4F7E-484C-A727-1BA876FEF1D3@opendnssec.org>
References: <20121205104057.GA12855@newphantom.local>
	<9CA5B06C-4F7E-484C-A727-1BA876FEF1D3@opendnssec.org>
Message-ID: <1FA8ED89-1B06-449C-8B2C-7DC34731A507@opendnssec.org>

On Dec 11, 2012, at 16:19 , Jerry Lundstr?m wrote:

> I will installed bind on redhat64-ods08, the CentOS server is to be converted into 32bit Red Hat.


Installed.

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



From matthijs at nlnetlabs.nl  Tue Dec 11 15:26:13 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Tue, 11 Dec 2012 16:26:13 +0100
Subject: [Opendnssec-develop] Re: [Opendnssec-user]How to speed up signing
	performance
In-Reply-To: <CAGTFMNZ4+OfNNBCg90k4eF8sFPsfsJD778cXEmt1eK0sUi4HQQ@mail.gmail.com>
References: <201208311414234414091125@126.com>
	<alpine.LFD.2.02.1208311257080.17923@bofh.nohats.ca>
	<CAGTFMNZPArySPxoR7Uh8MepdULZCsuhTrfYD5UCEf6r1DytL8g@mail.gmail.com>
	<alpine.LFD.2.02.1209051654270.20204@bofh.nohats.ca>
	<50ACF46B.7080006@nlnetlabs.nl>
	<CAGTFMNZ4+OfNNBCg90k4eF8sFPsfsJD778cXEmt1eK0sUi4HQQ@mail.gmail.com>
Message-ID: <50C75095.6090802@nlnetlabs.nl>

On 12/10/2012 09:10 AM, Jerry Lundstr?m wrote:
> Hi,
> 
> On Wed, Nov 21, 2012 at 4:34 PM, Matthijs Mekking <matthijs at nlnetlabs.nl> wrote:
>> The cpu patch was incorporated and is already included in the 1.4 beta.
>>
>> The aggressive retry patch is also applied, with small adjustments:
>>
>> -        if (status == ODS_STATUS_UNCHANGED) {
>> -            worker_wait_timeout_locked(&q->q_lock, &q->q_nonfull, 60);
>> +        if (!tries && status == ODS_STATUS_UNCHANGED) {
>> +            worker_wait_timeout_locked(&q->q_lock, &q->q_nonfull, 5);
>>          }
>>
>> The waiting should only occur when the number of max tries has been
>> reached (tries has been reset to 0). Also, 60 seconds seems indeed a
>> long maximum wait, 5 will do too (If the queue is not full, the timeout
>> should of course be shorter). This change is for now only in trunk, it
>> will be in the 1.4 rc.
> 
> I feel that the assumption that 60 seconds is a long time to wait is false.
> 
> If the locking/condition/signal code for the workers was working then
> you could actually wait forever because it would be signaled when
> there is more work.

True, but it should not take 60 seconds before the queue becomes
non-full (non-full is lower than 10 percent full). With your argument,
we could also set it to 0: only stop waiting until the queue is empty
enough again.

> Seeing that this patch has been introduced then it means that that
> code does not work as it should and it could lead to more problems
> like dead locks / slow downs and CPU hogging.

Perhaps the code does not work well, the more reason to let the worker
not wait that long. The 60 seconds is the bottleneck at the moment for
.ca apparently, so decreasing it to 5 seconds doesn't seem a slow down
to me.

Also note that we wait less often, only if tries is reset, we will wait.
In other words, we will try 10 times queuing the RRset before going in
wait mode. And we will start trying again in 5 seconds (or if the queue
becomes non-full, whichever comes first).

When all writing this down, I think why it is waiting for 60 seconds
(and now 5 seconds):

in worker_queue_rrset():
- lock sign queue for queuing another RRset
- sign queue is full, let's take a small break (5 or 60 seconds)

in worker_drudge():
- try get lock sign queue, for popping RRset, but sign queue is full

in worker_queue_rrset():
- stop waiting, unlock sign queue
- continue while loop.

Now there are some iterations for popping and pushing, and perhaps we
hit another 'small break'.

So, tuning down the 60 second wait to 5 seconds is a quick hack fix. I
think the real fix is waiting in worker_queue_rrset() without holding
the q_lock. Perhaps we need an push lock...


Best regards,
  Matthijs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121211/6018f75f/attachment.bin>

From matthijs at nlnetlabs.nl  Wed Dec 12 12:43:18 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Wed, 12 Dec 2012 13:43:18 +0100
Subject: [Opendnssec-develop] Re: [Opendnssec-user]How to speed up signing
	performance
In-Reply-To: <50C75095.6090802@nlnetlabs.nl>
References: <201208311414234414091125@126.com>
	<alpine.LFD.2.02.1208311257080.17923@bofh.nohats.ca>
	<CAGTFMNZPArySPxoR7Uh8MepdULZCsuhTrfYD5UCEf6r1DytL8g@mail.gmail.com>
	<alpine.LFD.2.02.1209051654270.20204@bofh.nohats.ca>
	<50ACF46B.7080006@nlnetlabs.nl>
	<CAGTFMNZ4+OfNNBCg90k4eF8sFPsfsJD778cXEmt1eK0sUi4HQQ@mail.gmail.com>
	<50C75095.6090802@nlnetlabs.nl>
Message-ID: <50C87BE6.9090006@nlnetlabs.nl>

Follow-up.

On 12/11/2012 04:26 PM, Matthijs Mekking wrote:
> When all writing this down, I think why it is waiting for 60 seconds
> (and now 5 seconds):
> 
> in worker_queue_rrset():
> - lock sign queue for queuing another RRset
> - sign queue is full, let's take a small break (5 or 60 seconds)

This is probably a flawed assumption, because the small break is
unlocking the mutex, and locking it when the wait is over. So the
drudgers should have no problem popping RRsets.

> 
> in worker_drudge():
> - try get lock sign queue, for popping RRset, but sign queue is full
> 
> in worker_queue_rrset():
> - stop waiting, unlock sign queue
> - continue while loop.
> 
> Now there are some iterations for popping and pushing, and perhaps we
> hit another 'small break'.
> 
> So, tuning down the 60 second wait to 5 seconds is a quick hack fix. I
> think the real fix is waiting in worker_queue_rrset() without holding
> the q_lock. Perhaps we need an push lock...
> 
> 
> Best regards,
>   Matthijs
> 
> 
> 
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121212/a9eaf023/attachment.bin>

From sara at sinodun.com  Thu Dec 13 10:16:27 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 13 Dec 2012 10:16:27 +0000
Subject: [Opendnssec-develop] Meeting on the 18th
In-Reply-To: <50C71980.5000603@nlnetlabs.nl>
References: <50C71463.8000204@nominet.org.uk> <50C71876.4040002@nlnetlabs.nl>
	<50C71980.5000603@nlnetlabs.nl>
Message-ID: <AD8A14B9-D5D0-4985-8EC9-848890CE50B1@sinodun.com>


17th is fine by me too. So new date/time is: Monday 17th December @ 14:00 CET

Sara.

On 11 Dec 2012, at 11:31, Matthijs Mekking wrote:

> Same here
> 
> On 12/11/2012 12:26 PM, Yuri Schaeffer wrote:
>>> I won't be able to make the meeting that we have scheduled for the 18th.
>>> Could we move it a day either way?
>> 
>> 17th would work and 19 would not work for me.
>> _______________________________________________
>> 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 sara at sinodun.com  Thu Dec 13 10:31:00 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 13 Dec 2012 10:31:00 +0000
Subject: [Opendnssec-develop] RE: 1.3.12 release candidate
In-Reply-To: <50C5BC59.2020002@nlnetlabs.nl>
References: <F168587B-17DC-4962-BA43-036F349B9685@sinodun.com>
	<624F002A-AC0C-4D9A-BF4B-F3EB03F92DE5@sinodun.com>
	<CAGTFMNZeFaMoJPf-2sso-MLbR7YF4gzqyAb5N+skbroqc7vAYQ@mail.gmail.com>
	<6079AF48-DF6C-4617-8AFB-083EAA3B8228@sinodun.com>
	<50C5BC59.2020002@nlnetlabs.nl>
Message-ID: <4B4474FC-B186-47A4-8912-347EBF5B4183@sinodun.com>


On 10 Dec 2012, at 10:41, Matthijs Mekking wrote:

> We could also 'tag' the release candidate. Tagging means making no
> changes to them. If changes are required, they are made in the branch.
> If changes are made, a new rc is created from branch. Advantages: No
> need for merging and no need to freeze the branch.
> 

On other products I have worked on the only changes allowed between an RC and full release were fixes to issues found with the RC (e.g. build issues or a critical bug fix that didn't work properly).  Nothing 'new' was allowed in even if the RC was re-issued. 

Doing what you suggest means that if someone puts a fix in the branch for something that wasn't in the original RC and then you need a new RC for some reason, then that new fix ends up in the new RC..... Also the danger is that the new fix breaks something, or you have to wait for it to be tested, etc. and the release is delayed again.... 

Sara.


> Best regards,
>  Matthijs
> 
> On 12/10/2012 11:38 AM, Sara Dickinson wrote:
>> Hi Jerry, 
>> 
>> It is a good point that it isn't necessary but based on discussions in the team meetings and the fact it has been documented as part of the process for some time now I took this as what we had agreed to do.
>> 
>> We could alternatively do as suggested below however I would not vote in favour of this. I prefer freezing the branch as it is a much simpler approach and is less error prone than having to merge changes. I would suggest we continue with the current process and if we do find it to be an issue then we could review things. However if others feel differently then please speak up! 
>> 
>> Sara.
>> 
>> On 10 Dec 2012, at 07:55, Jerry Lundstr?m wrote:
>> 
>>> Hi,
>>> 
>>> On Mon, Nov 26, 2012 at 3:05 PM, Sara Dickinson <sara at sinodun.com> wrote:
>>>> Since we have a release candidate issued please refrain from submitting routine code into the 1.3.12 branch until the full release is done. If you have a high priority issue that you believe warrants the re-issue of the release candidate please email the developers list first so this can be agreed.
>>> 
>>> It isn't necessary to "lock" the branch while a release candidate is issued.
>>> 
>>> You can copy the release candidate tag once it is decided to release
>>> the full version and if any change had been made that should be
>>> included in the release you can merge it with the release tag after
>>> copy.
>>> 
>>> -- 
>>> Jerry Lundstr?m - OpenDNSSEC Developer
>>> http://www.opendnssec.org/
>> 
>> _______________________________________________
>> 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 sara at sinodun.com  Thu Dec 13 10:47:57 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 13 Dec 2012 10:47:57 +0000
Subject: [Opendnssec-develop] RE: Regression testing update
In-Reply-To: <CAGTFMNZ6ig6LF9nAXJR1WD=HzZ=cRY2kso9X68F-sc0UtK1DOQ@mail.gmail.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<CAGTFMNZ6ig6LF9nAXJR1WD=HzZ=cRY2kso9X68F-sc0UtK1DOQ@mail.gmail.com>
Message-ID: <05D44EAF-E170-4EE4-A144-B595E5F0DFBE@sinodun.com>


On 11 Dec 2012, at 08:51, Jerry Lundstr?m wrote:

> Hi,
> 
> On Mon, Nov 26, 2012 at 4:03 PM, Sara Dickinson <sara at sinodun.com> wrote:
>> I've had a go at the first two so am looking for some feedback before moving any further.... More details on both the following suggestions are on the wiki page: https://wiki.opendnssec.org/display/OpenDNSSEC/Test+case+policy
> 
> Policy looks good.
> 
>> Naming
> 
> What ever we agree on is fine by me as long as we all use the same.

Thanks. 

> 
>> Tracking
> 
> This is fine as long as it does not make the test case directories in
> each branch the "master database" of what is to be tested. In other
> words; I would rather have the wiki as a master saying what kinds of
> tests we should have and then maybe auto generate tests into each
> branch then adding the test code for that branch for those specific
> cases.

I'm not sure I understand what you mean here. The idea is that the script output tells you "what is currently tested" by looking directly at the existing tests in the branches and the wiki will be a wish list of what tests we still need to add. 

Can you elaborate on your idea for auto generating tests?

> 
> Also, could we move that script out from the OpenDNSSEC trunk branch
> into maybe trunk/testing ?
> 

Sure - would trunk/testing/framework be the best place? Or I was wondering if we could make it a function in the lib.sh file (it has a lot in common with the run_tests() function) and then it will get platform dependancy for free. 

Sara.

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



From sion at nominet.org.uk  Thu Dec 13 11:01:17 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Thu, 13 Dec 2012 11:01:17 +0000
Subject: [Opendnssec-develop] Meeting on the 18th
In-Reply-To: <AD8A14B9-D5D0-4985-8EC9-848890CE50B1@sinodun.com>
References: <50C71463.8000204@nominet.org.uk> <50C71876.4040002@nlnetlabs.nl>
	<50C71980.5000603@nlnetlabs.nl>
	<AD8A14B9-D5D0-4985-8EC9-848890CE50B1@sinodun.com>
Message-ID: <50C9B57D.5000209@nominet.org.uk>

On 13/12/12 10:16, Sara Dickinson wrote:
> 17th is fine by me too. So new date/time is: Monday 17th December @ 14:00 CET
>
> Sara.
>
>

Thank you


From sara at sinodun.com  Thu Dec 13 13:51:53 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 13 Dec 2012 13:51:53 +0000
Subject: [Opendnssec-develop] RE: Process for tracking bugs
In-Reply-To: <CAGTFMNYBgfutGFiO6qo5n4z2+fDoGy+6o4i+PPRY4S9z-s=h3g@mail.gmail.com>
References: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
	<CAGTFMNYBgfutGFiO6qo5n4z2+fDoGy+6o4i+PPRY4S9z-s=h3g@mail.gmail.com>
Message-ID: <AC427E9A-BA20-4F42-A772-47969D250D76@sinodun.com>


On 11 Dec 2012, at 09:02, Jerry Lundstr?m wrote:

> Hi,
> 
> On Tue, Dec 4, 2012 at 4:40 PM, Sara Dickinson <sara at sinodun.com> wrote:
>> https://wiki.opendnssec.org/display/OpenDNSSEC/Bug+tracking+process
> 
> Looks good, I just have two comment:
> 
> "Resolve - Add a comment to the issue with the svn revision(s) (or
> even better, a fisheye link to the revision)."
> 
> This is not be necessary if you tagged the commit correctly, it will
> show up in the JIRA issue if you select All or Source tab (which is
> why we have FishEye after all).

Good point - I will update to say this is only needed if the commit wasn't tagged. 

> 
> "Resolve - Clearly state what branches have been fixed."
> 
> This can be simplified if we start using different issues for
> different branches/versions, for example if a problem might be related
> to 2 or more branches/versions you make an issue about the problem
> then create subtasks / linked issues for each related branch/version.

Another good point. Do we want to change the process to this? It has pros and cons:

+ the issue state will show the different stage of fixes in different branches
+ harder to forget to do branch specific documentation, jenkins tests, etc if there is a dedicated issue for each branch

- more overhead as more issues created
- harder to see what branches a fix affects as you have to pull up at least 2 JIRA issues, rather than just looking at one field 
- requires the fixes for different branches to go in different commits for the jira <-> fisheye link to work
- could be confusing since in the NEWS file fixes for the same issue will have different issue numbers in different branches. 

On balance I prefer what we do now i.e. one issue for all branches. Anyone else?

Sara.


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



From sara at sinodun.com  Thu Dec 13 13:55:40 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 13 Dec 2012 13:55:40 +0000
Subject: [Opendnssec-develop] Meeting notes 2012-12-03
In-Reply-To: <1FA8ED89-1B06-449C-8B2C-7DC34731A507@opendnssec.org>
References: <20121205104057.GA12855@newphantom.local>
	<9CA5B06C-4F7E-484C-A727-1BA876FEF1D3@opendnssec.org>
	<1FA8ED89-1B06-449C-8B2C-7DC34731A507@opendnssec.org>
Message-ID: <D4408F02-6A98-4EF7-952F-B7CB8CACAE69@sinodun.com>


On 11 Dec 2012, at 15:25, Jerry Lundstr?m wrote:

> On Dec 11, 2012, at 16:19 , Jerry Lundstr?m wrote:
> 
>> I will installed bind on redhat64-ods08, the CentOS server is to be converted into 32bit Red Hat.
> 
> Installed.

Great - thank you!

On 11 Dec 2012, at 15:19, Jerry Lundstr?m wrote:

> 
> There is currently no way to just run a test on a single platform so the test needs to run on all platforms and it could do a case on $DISTRIBUTION (as in most build-*.sh) to only do the test on redhat and return 0 on all other platforms.
> 

Yes - this was what I was thinking of for now. 

Sara.



From sara at sinodun.com  Fri Dec 14 13:58:06 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Fri, 14 Dec 2012 13:58:06 +0000
Subject: Fwd: [Opendnssec-develop] RE: 1.4.0b2 release
References: <2196185E-89AD-4F6F-8107-8FD4136ACE47@sinodun.com>
Message-ID: <EF253724-14B7-4D76-9D37-DF534283DF9A@sinodun.com>

Hi All, 

The issues with the release are now all resolved so if there are no objections I would like to go ahead with the 1.4.0b2 release asap.

Thanks

Sara.



From sion at nominet.org.uk  Fri Dec 14 14:20:53 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Fri, 14 Dec 2012 14:20:53 +0000
Subject: Fwd: [Opendnssec-develop] RE: 1.4.0b2 release
In-Reply-To: <EF253724-14B7-4D76-9D37-DF534283DF9A@sinodun.com>
References: <2196185E-89AD-4F6F-8107-8FD4136ACE47@sinodun.com>
	<EF253724-14B7-4D76-9D37-DF534283DF9A@sinodun.com>
Message-ID: <50CB35C5.9060603@nominet.org.uk>

On 14/12/12 13:58, Sara Dickinson wrote:
> Hi All, 
>
> The issues with the release are now all resolved so if there are no objections I would like to go ahead with the 1.4.0b2 release asap.
>
> Thanks
>
> Sara.
>
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

No objection from me, one comment though... Freds issue highlighted the
fact that the "backup done" command changes between the two beta
versions. this should be communicated clearly.

Sion


From sara at sinodun.com  Sun Dec 16 19:58:40 2012
From: sara at sinodun.com (Sara (Sinodun))
Date: Sun, 16 Dec 2012 19:58:40 +0000
Subject: [Opendnssec-develop] RE: Team Meeting - Monday 17th Dec @ 14.00 CET
References: <B0DF8E63-F364-48F0-87A9-28B36F78574A@sinodun.com>
Message-ID: <19996BBF-FC80-4CB6-B8E1-A574F05FAD12@sinodun.com>

Hi All, 

We have a team meeting on Monday:

Date:      Monday 17 December 2012
Time:      14:00-15:00 CET, 13:00-14:00 GMT
Method:  Google+
Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2012-12-17+Agenda

Sara.

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

From jerry at opendnssec.org  Mon Dec 17 08:49:28 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 17 Dec 2012 09:49:28 +0100
Subject: [Opendnssec-develop] Regression testing update
In-Reply-To: <05D44EAF-E170-4EE4-A144-B595E5F0DFBE@sinodun.com>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<CAGTFMNZ6ig6LF9nAXJR1WD=HzZ=cRY2kso9X68F-sc0UtK1DOQ@mail.gmail.com>
	<05D44EAF-E170-4EE4-A144-B595E5F0DFBE@sinodun.com>
Message-ID: <5B87B1A7-C840-4E83-8059-EE269B90C20A@opendnssec.org>

On Dec 13, 2012, at 11:47 , Sara Dickinson wrote:

>>> Tracking
>> 
>> This is fine as long as it does not make the test case directories in
>> each branch the "master database" of what is to be tested. In other
>> words; I would rather have the wiki as a master saying what kinds of
>> tests we should have and then maybe auto generate tests into each
>> branch then adding the test code for that branch for those specific
>> cases.
> 
> I'm not sure I understand what you mean here. The idea is that the script output tells you "what is currently tested" by looking directly at the existing tests in the branches and the wiki will be a wish list of what tests we still need to add. 

I feel that the Wiki should not be a "wish list", we should have a clear list of what should be tested.

>> Also, could we move that script out from the OpenDNSSEC trunk branch
>> into maybe trunk/testing ?
> 
> Sure - would trunk/testing/framework be the best place? Or I was wondering if we could make it a function in the lib.sh file (it has a lot in common with the run_tests() function) and then it will get platform dependancy for free. 


I don't feel that this should be included into lib.sh because its meant to hold functions related to running tests on all different platforms. This extraction is not meant to be done on the platforms, its rather don't manually on a developers computer so there is no need to have it in lib.sh.

Straight into trunk/testing is a better place for this.

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



From jerry at opendnssec.org  Mon Dec 17 08:54:02 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 17 Dec 2012 09:54:02 +0100
Subject: [Opendnssec-develop] Process for tracking bugs
In-Reply-To: <AC427E9A-BA20-4F42-A772-47969D250D76@sinodun.com>
References: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
	<CAGTFMNYBgfutGFiO6qo5n4z2+fDoGy+6o4i+PPRY4S9z-s=h3g@mail.gmail.com>
	<AC427E9A-BA20-4F42-A772-47969D250D76@sinodun.com>
Message-ID: <83D7F797-2614-4313-871B-0F85088CB458@opendnssec.org>

On Dec 13, 2012, at 14:51 , Sara Dickinson wrote:

> - more overhead as more issues created
> - harder to see what branches a fix affects as you have to pull up at least 2 JIRA issues, rather than just looking at one field 

This depends on how we do it, how we search. We have affected versions and fixed versions, the main issue can affect both version but the subtasks could only specify one affected version and one fixed version.

> - requires the fixes for different branches to go in different commits for the jira <-> fisheye link to work

No, I don't believe it only takes the first matched JIRA issue tag. If you commit for both branches at the same time and specify both issue tags it should work.

> - could be confusing since in the NEWS file fixes for the same issue will have different issue numbers in different branches. 

You could specify the main issue in the NEWS and not the subtasks.

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



From jerry at opendnssec.org  Mon Dec 17 08:58:44 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 17 Dec 2012 09:58:44 +0100
Subject: [Opendnssec-develop] [Opendnssec-user]How to speed up signing
	performance
In-Reply-To: <50C87BE6.9090006@nlnetlabs.nl>
References: <201208311414234414091125@126.com>
	<alpine.LFD.2.02.1208311257080.17923@bofh.nohats.ca>
	<CAGTFMNZPArySPxoR7Uh8MepdULZCsuhTrfYD5UCEf6r1DytL8g@mail.gmail.com>
	<alpine.LFD.2.02.1209051654270.20204@bofh.nohats.ca>
	<50ACF46B.7080006@nlnetlabs.nl>
	<CAGTFMNZ4+OfNNBCg90k4eF8sFPsfsJD778cXEmt1eK0sUi4HQQ@mail.gmail.com>
	<50C75095.6090802@nlnetlabs.nl> <50C87BE6.9090006@nlnetlabs.nl>
Message-ID: <2B3EA0BF-5673-4EB4-8582-7A69843EB76C@opendnssec.org>

On Dec 12, 2012, at 13:43 , Matthijs Mekking wrote:

> This is probably a flawed assumption, because the small break is
> unlocking the mutex, and locking it when the wait is over. So the
> drudgers should have no problem popping RRsets.


I see that you have made changes during last week so this might not be an issue now.

But my point was that no matter how long we wait, if the code uses mutex/cond correctly it will be notified when there is work. Reducing it is just a workaround and not a fix to the real problem (and that can result in other "strange" problems in the future).

How has this gone now with the changes you have made?

--
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/20121217/dd6abeef/attachment.bin>

From matthijs at nlnetlabs.nl  Mon Dec 17 11:13:27 2012
From: matthijs at nlnetlabs.nl (Matthijs Mekking)
Date: Mon, 17 Dec 2012 12:13:27 +0100
Subject: [Opendnssec-develop] [Opendnssec-user]How to speed up signing
	performance
In-Reply-To: <2B3EA0BF-5673-4EB4-8582-7A69843EB76C@opendnssec.org>
References: <201208311414234414091125@126.com>
	<alpine.LFD.2.02.1208311257080.17923@bofh.nohats.ca>
	<CAGTFMNZPArySPxoR7Uh8MepdULZCsuhTrfYD5UCEf6r1DytL8g@mail.gmail.com>
	<alpine.LFD.2.02.1209051654270.20204@bofh.nohats.ca>
	<50ACF46B.7080006@nlnetlabs.nl>
	<CAGTFMNZ4+OfNNBCg90k4eF8sFPsfsJD778cXEmt1eK0sUi4HQQ@mail.gmail.com>
	<50C75095.6090802@nlnetlabs.nl> <50C87BE6.9090006@nlnetlabs.nl>
	<2B3EA0BF-5673-4EB4-8582-7A69843EB76C@opendnssec.org>
Message-ID: <50CEFE57.5010309@nlnetlabs.nl>

On 12/17/2012 09:58 AM, Jerry Lundstr?m wrote:
> On Dec 12, 2012, at 13:43 , Matthijs Mekking wrote:
> 
>> This is probably a flawed assumption, because the small break is 
>> unlocking the mutex, and locking it when the wait is over. So the 
>> drudgers should have no problem popping RRsets.
> 
> 
> I see that you have made changes during last week so this might not
> be an issue now.
> 
> But my point was that no matter how long we wait, if the code uses
> mutex/cond correctly it will be notified when there is work. Reducing
> it is just a workaround and not a fix to the real problem (and that
> can result in other "strange" problems in the future).

I agreed with the fix to decrease the waiting time to be a workaround,
but it would be a better value for waiting time. 60 seconds is too long
if you would end up hitting this code path. If only after 5 seconds, the
signer continued signing, the 'damage' is not that big.

I claim that 5 seconds is long enough wait, but that depends on the
speed of the signer. The queue is 1000 items big, so after 900
signatures created, or after 5 seconds, the worker will start queuing
RRsets again. Only if the signer is slower than 180 RRSIGS/sec, the 5
seconds timeout will kick in.

> How has this gone now with the changes you have made?

It was mainly .ca who had problems with this. They run a patched beta1,
and they don't have a bunch of fixes which are made in trunk. I think
your fix, r6642, is the real fix for this.

My commits from the past few days are mainly documentation + I applied
the r6642 fix also to worker_queue_rrset() (lock; push; if failed:
{sleep; push}; unlock)

Also, I use lock_basic_sleep directly and removed wrapper functions
worker_wait_locked and worker_wait_timeout_locked. This introduces no
behavioral changes.

Best regards,
  Matthijs


> 
> -- 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: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121217/05fffe4b/attachment.bin>

From sion at nominet.org.uk  Mon Dec 17 11:30:18 2012
From: sion at nominet.org.uk (=?ISO-8859-1?Q?Si=F4n_Lloyd?=)
Date: Mon, 17 Dec 2012 11:30:18 +0000
Subject: [Opendnssec-develop] Regression testing update
In-Reply-To: <5B87B1A7-C840-4E83-8059-EE269B90C20A@opendnssec.org>
References: <C55D5AA3-B7D1-4C44-8075-71B288A725DB@sinodun.com>
	<CAGTFMNZ6ig6LF9nAXJR1WD=HzZ=cRY2kso9X68F-sc0UtK1DOQ@mail.gmail.com>
	<05D44EAF-E170-4EE4-A144-B595E5F0DFBE@sinodun.com>
	<5B87B1A7-C840-4E83-8059-EE269B90C20A@opendnssec.org>
Message-ID: <50CF024A.9080804@nominet.org.uk>

On 17/12/12 08:49, Jerry Lundstr?m wrote:
> On Dec 13, 2012, at 11:47 , Sara Dickinson wrote:
>
>>>> Tracking
>>> This is fine as long as it does not make the test case directories in
>>> each branch the "master database" of what is to be tested. In other
>>> words; I would rather have the wiki as a master saying what kinds of
>>> tests we should have and then maybe auto generate tests into each
>>> branch then adding the test code for that branch for those specific
>>> cases.
>> I'm not sure I understand what you mean here. The idea is that the script output tells you "what is currently tested" by looking directly at the existing tests in the branches and the wiki will be a wish list of what tests we still need to add. 
> I feel that the Wiki should not be a "wish list", we should have a clear list of what should be tested.
>

>From experience, keeping test documentation up to date is prone to
error. If they can be made as "self documenting" as possible then this
is more likely to reflect what is actually tested. Of course we still
rely on comments being kept up to date, but the overhead is smaller.

Sion


From sara at sinodun.com  Mon Dec 17 12:00:40 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 17 Dec 2012 12:00:40 +0000
Subject: [Opendnssec-develop] Process for tracking bugs
In-Reply-To: <83D7F797-2614-4313-871B-0F85088CB458@opendnssec.org>
References: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
	<CAGTFMNYBgfutGFiO6qo5n4z2+fDoGy+6o4i+PPRY4S9z-s=h3g@mail.gmail.com>
	<AC427E9A-BA20-4F42-A772-47969D250D76@sinodun.com>
	<83D7F797-2614-4313-871B-0F85088CB458@opendnssec.org>
Message-ID: <072061EA-3EA2-4151-824A-BB609C43BD62@sinodun.com>


On 17 Dec 2012, at 08:54, Jerry Lundstr?m wrote:

> On Dec 13, 2012, at 14:51 , Sara Dickinson wrote:
> 
>> - more overhead as more issues created
>> - harder to see what branches a fix affects as you have to pull up at least 2 JIRA issues, rather than just looking at one field 
> 
> This depends on how we do it, how we search. We have affected versions and fixed versions, the main issue can affect both version but the subtasks could only specify one affected version and one fixed version.

So we need n+1 issues for each fix where n is the number of branches affected? And you will see 2 issues when you do a JIRA query against a given release (main and sub-task).

> 
>> - requires the fixes for different branches to go in different commits for the jira <-> fisheye link to work
> 
> No, I don't believe it only takes the first matched JIRA issue tag. If you commit for both branches at the same time and specify both issue tags it should work.

OK - this is good to know, thanks.

> 
>> - could be confusing since in the NEWS file fixes for the same issue will have different issue numbers in different branches. 
> 
> You could specify the main issue in the NEWS and not the subtasks.

Erm... sounds more complicated that what we do now so I still vote to stick with what we have ;-)

Sara.

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



From jerry at opendnssec.org  Mon Dec 17 12:23:06 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 17 Dec 2012 13:23:06 +0100
Subject: [Opendnssec-develop] Process for tracking bugs
In-Reply-To: <072061EA-3EA2-4151-824A-BB609C43BD62@sinodun.com>
References: <693A9978-E0B3-434B-B0B0-BA0828BC04B0@sinodun.com>
	<CAGTFMNYBgfutGFiO6qo5n4z2+fDoGy+6o4i+PPRY4S9z-s=h3g@mail.gmail.com>
	<AC427E9A-BA20-4F42-A772-47969D250D76@sinodun.com>
	<83D7F797-2614-4313-871B-0F85088CB458@opendnssec.org>
	<072061EA-3EA2-4151-824A-BB609C43BD62@sinodun.com>
Message-ID: <12788BF2-0B2D-43C5-B5BF-C6029738D7C8@opendnssec.org>

On Dec 17, 2012, at 13:00 , Sara Dickinson wrote:

> So we need n+1 issues for each fix where n is the number of branches affected? And you will see 2 issues when you do a JIRA query against a given release (main and sub-task).

Not if you search with '... issuetype != "Technical task" ...'.

>>> - could be confusing since in the NEWS file fixes for the same issue will have different issue numbers in different branches. 
>> 
>> You could specify the main issue in the NEWS and not the subtasks.
> 
> Erm... sounds more complicated that what we do now so I still vote to stick with what we have ;-)


Well, this is a lot of "project manager" stuff so if you find it easier to keep track another way then by all means.

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



From jerry at opendnssec.org  Mon Dec 17 12:31:17 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Mon, 17 Dec 2012 13:31:17 +0100
Subject: [Opendnssec-develop] Re: Server at SURFnet for large tests is up
	but no network (titan.buildfarm.opendnssec.org)
In-Reply-To: <6A76F8E0-1170-4AC8-863E-36AA7D02513E@opendnssec.org>
References: <6A76F8E0-1170-4AC8-863E-36AA7D02513E@opendnssec.org>
Message-ID: <47CAD6B8-FEFC-43A5-8768-BE6EE053A4E2@opendnssec.org>

On Dec 11, 2012, at 16:14 , Jerry Lundstr?m wrote:

> As subject, its up and installed but I have not gotten the network details so it can't be reached yet.


titan is now online and added to Jenkins, all developers have access to readonly at 145.100.186.149 (DNS not added yet).

--
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/20121217/e96fe4e3/attachment.bin>

From sara at sinodun.com  Mon Dec 17 16:32:55 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Mon, 17 Dec 2012 16:32:55 +0000
Subject: [Opendnssec-develop] RE: Team Meeting - Monday 17th Dec @ 14.00 CET
References: <19996BBF-FC80-4CB6-B8E1-A574F05FAD12@sinodun.com>
Message-ID: <48100B2D-32D7-48C1-8935-F6C1F79B4DBB@sinodun.com>

All, 

The minutes from today are available for review:

https://wiki.opendnssec.org/display/OpenDNSSEC/2012-12-17+Minutes

Please correct/update as required!

Sara.

Begin forwarded message:

> From: "Sara (Sinodun)" <sara at sinodun.com>
> Date: 16 December 2012 19:58:40 GMT
> To: Opd Dev <opendnssec-develop at lists.opendnssec.org>
> Subject: [Opendnssec-develop] RE: Team Meeting - Monday 17th Dec @ 14.00 CET
> 
> Hi All, 
> 
> We have a team meeting on Monday:
> 
> Date:      Monday 17 December 2012
> Time:      14:00-15:00 CET, 13:00-14:00 GMT
> Method:  Google+
> Agenda:  https://wiki.opendnssec.org/display/OpenDNSSEC/2012-12-17+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/20121217/c38aad23/attachment.htm>

From sara at sinodun.com  Tue Dec 18 12:14:01 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Tue, 18 Dec 2012 12:14:01 +0000
Subject: [Opendnssec-develop] Fwd: Performance benchmarks
References: <534DA3E3-3284-4F97-B178-CFF7F5C72C6D@sinodun.com>
Message-ID: <2F380956-6749-4DEC-BFAC-8E3E41603345@sinodun.com>

Hi All, 

Firstly thanks to Jerry and SurfNet for getting the benchmarking hardware up and running! Now - what do we do with it?

I looked back at the minutes from the last OAB meeting and two of the specific things mentioned about benchmarking were that 

- the benchmarks should demonstrate that a "reasonable" sized registrar can use OpenDNSSEC comfortably
- benchmarking was higher priority than endurance testing because we need to asses 1.4 vs 2.0

My own notes from the meeting also mention that there was a discussion about the 2.0 performance target. We (the developers) asked the board to clarify the target as all that had been said up to that point was that 2.0 "should handle 50,000 zones". The feeling was that this was too vague to really measure, but there wasn't any real agreement on what the target was apart from wanting to demonstrate something like the first bullet point above. 

My notes also show that there was a discussion about whether we did 
- 'one-shot' type benchmarking (measure sign and re-sign) on a few zone size/number combinations but with several different config options (no. of threads, NSEC, shared keys, etc.) or
- more dynamic testing e.g. start with 1 small zone and make measurements as N lots of X zones or records are added, with probably less config options tested.  

With the dynamic testing we would get a plot of how signing time/memory/etc. changes as the system grows. The feeling was that the second approach would be more useful and we should pick some tests to start with, see how hard they are to do,  publish the data and get feedback from the users.  

In general I think the aim of the benchmarking tests we develop should include the following:
- do direct comparisons between the new and current enforcer...
- provide data and monitor performance (time taken, memory usage) for the development team as code is added during development phases
- give us useful information to feedback to the users
- be the basis of some standard set ups that we can document

Maybe we should start with 2 'dynamic' tests
- grow from 1 small zone to 1 large zone by adding records (add 10 lots of 100,000 records)
- grow from 1 small zone to many small zones by adding zones (add 10 lots of 5,000 zones)
and see what this give us. 

What do people think?

Sara.




From jerry at opendnssec.org  Tue Dec 18 13:03:45 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 18 Dec 2012 14:03:45 +0100
Subject: [Opendnssec-develop] Performance benchmarks
In-Reply-To: <2F380956-6749-4DEC-BFAC-8E3E41603345@sinodun.com>
References: <534DA3E3-3284-4F97-B178-CFF7F5C72C6D@sinodun.com>
	<2F380956-6749-4DEC-BFAC-8E3E41603345@sinodun.com>
Message-ID: <D79ECB5F-F7A8-4DB8-9D2A-16CE7612EBDF@opendnssec.org>

On Dec 18, 2012, at 13:14 , Sara Dickinson wrote:

> Maybe we should start with 2 'dynamic' tests

Sounds like a good start.

> - grow from 1 small zone to 1 large zone by adding records (add 10 lots of 100,000 records)

This only affects the Signer and what is interesting to benchmark here is memory usage and not signing since that is almost fully depended on the HSM used.

> - grow from 1 small zone to many small zones by adding zones (add 10 lots of 5,000 zones)


This affects the Enforcer more then it does the Signer but we should benchmark both.

Whats really interesting here is to see the time it takes to handle many zones and to do normal operation stuff on a setup with many zones, so maybe something like this:

1) Add 500 zones
2) Randomly add and delete 10 zones
3) If total number zones < 10000 goto 1

Reason for just 10000 zones is that adding 50000 may take half a day on 1.3/1.4 so its better to start with something we know can finish in a day.

Is this something 2.0 is ready for yet btw or shall we just start with 1.3/1.4?

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



From jerry at opendnssec.org  Tue Dec 18 15:55:01 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Tue, 18 Dec 2012 16:55:01 +0100
Subject: [Opendnssec-develop] IPv6 problems to dist./svn.opendnssec.org
Message-ID: <7E45A2CA-0A85-4D12-ADA5-89481F39F797@opendnssec.org>

Hi,

I have noticed some IPv6 problems on the KVM running our repositories, looks like a problem with the KVM network drivers.

If you have problems try disabling IPv6 or forcing svn to use IPv4 until this is resolved.

--
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/20121218/c2b5ffe5/attachment.bin>

From sara at sinodun.com  Thu Dec 20 08:54:30 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 20 Dec 2012 08:54:30 +0000
Subject: [Opendnssec-develop] Performance benchmarks
In-Reply-To: <D79ECB5F-F7A8-4DB8-9D2A-16CE7612EBDF@opendnssec.org>
References: <534DA3E3-3284-4F97-B178-CFF7F5C72C6D@sinodun.com>
	<2F380956-6749-4DEC-BFAC-8E3E41603345@sinodun.com>
	<D79ECB5F-F7A8-4DB8-9D2A-16CE7612EBDF@opendnssec.org>
Message-ID: <BB9C3115-E65E-4B03-A831-0436F1DB4638@sinodun.com>


On 18 Dec 2012, at 13:03, Jerry Lundstr?m wrote:

Thanks for all the comments. 

> On Dec 18, 2012, at 13:14 , Sara Dickinson wrote:
> 
>> Maybe we should start with 2 'dynamic' tests
> 
> Sounds like a good start.
> 
>> - grow from 1 small zone to 1 large zone by adding records (add 10 lots of 100,000 records)
> 
> This only affects the Signer and what is interesting to benchmark here is memory usage and not signing since that is almost fully depended on the HSM used.

Does anyone know where he HSM's we have installed (SafeNet Luna SA 4) fall in the range of HSM's available? Does it at least give us a correct order of magnitude for timings?

> 
>> - grow from 1 small zone to many small zones by adding zones (add 10 lots of 5,000 zones)
> 
> 
> This affects the Enforcer more then it does the Signer but we should benchmark both.
> 
> Whats really interesting here is to see the time it takes to handle many zones and to do normal operation stuff on a setup with many zones, so maybe something like this:
> 
> 1) Add 500 zones
> 2) Randomly add and delete 10 zones
> 3) If total number zones < 10000 goto 1
> 
> Reason for just 10000 zones is that adding 50000 may take half a day on 1.3/1.4 so its better to start with something we know can finish in a day.

Yes - if we script it right then the number of zones to start with/add/remove are just parameters and we can start small and ramp it up. It is going to be a learning process :-)

> 
> Is this something 2.0 is ready for yet btw or shall we just start with 1.3/1.4?

As far as I know 1.4 should be able to handle this (Yuri?) although I think there may be issues with shared keys. I would be tempted to develop the scripts against 1.3 since it shouldn't have any surprises, then try them with a smallish number of zones (500?) on 1.4 and 2.0 just to make sure it works. Then do a larger runs against each release and see what happens....

Sara. 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121220/812fe7d0/attachment.htm>

From jerry at opendnssec.org  Thu Dec 20 09:16:01 2012
From: jerry at opendnssec.org (=?iso-8859-1?Q?Jerry_Lundstr=F6m?=)
Date: Thu, 20 Dec 2012 10:16:01 +0100
Subject: [Opendnssec-develop] Performance benchmarks
In-Reply-To: <BB9C3115-E65E-4B03-A831-0436F1DB4638@sinodun.com>
References: <534DA3E3-3284-4F97-B178-CFF7F5C72C6D@sinodun.com>
	<2F380956-6749-4DEC-BFAC-8E3E41603345@sinodun.com>
	<D79ECB5F-F7A8-4DB8-9D2A-16CE7612EBDF@opendnssec.org>
	<BB9C3115-E65E-4B03-A831-0436F1DB4638@sinodun.com>
Message-ID: <B4556DCE-8DC9-4A87-B9DD-E2F96A26D1F3@opendnssec.org>

On Dec 20, 2012, at 09:54 , Sara Dickinson wrote:

> On 18 Dec 2012, at 13:03, Jerry Lundstr?m wrote:
>> Is this something 2.0 is ready for yet btw or shall we just start with 1.3/1.4?
> 
> As far as I know 1.4 should be able to handle this (Yuri?) although I think there may be issues with shared keys. I would be tempted to develop the scripts against 1.3 since it shouldn't have any surprises, then try them with a smallish number of zones (500?) on 1.4 and 2.0 just to make sure it works. Then do a larger runs against each release and see what happens....


The only thing we changed in the Enforcer 1.3 -> 1.4 is adding multithreaded code that is optional. That code is meant to make it run better with 1000's of zones not 10.000's of zones.

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



From sara at sinodun.com  Thu Dec 20 12:49:54 2012
From: sara at sinodun.com (Sara Dickinson)
Date: Thu, 20 Dec 2012 12:49:54 +0000
Subject: [Opendnssec-develop] RE: New pages in 1.4 documentation
Message-ID: <B8A075D6-C537-4973-BF63-643EB7CAD33D@sinodun.com>

Hi All, 

I've update the following page based on reviewing the NEWS file for notable updates:

https://wiki.opendnssec.org/display/DOCSTRUNK/New+in+OpenDNSSEC+1.4

Please let me know if there is anything important missing from here!


Also - I have added several new pages underneath the 'Overview' section:

https://wiki.opendnssec.org/display/DOCSTRUNK/Overview+of+OpenDNSSEC

and also tweaked the architecture diagram, etc after some discussions with Matthijs. The content of the 'quick guide' page is based on the questions we frequently get on the users list. Any and all comments/feedback/proof reading gratefully received!

Sara.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20121220/e31c6aee/attachment.htm>