[bind10-dev] hardening sprint thoughts

[Shane Kerr]

Jinmei,

On Wednesday, 2012-03-14 10:44:49 -0700, 
JINMEI Tatuya / 神明達哉 <jinmei at isc.org> wrote:
> A couple of related points:
> 
> - I suspect it could be possible some of the letfover stuff turns out
>   to be too minor on revisiting it after some period of time (even if
>   when the follow up ticket was created we thought it a MUST but just
>   deferred due to time constraint).  So it's also good to close such
>   tickets immediately using an opportunity like "hardening".  One
>   concern in this sense is that the last sprint of the same release
>   cycle may be too soon to make such a decision, and we may end up
>   working on really minor things.

Having gone through a few hundred tickets, there are not too many
tickets that can be closed because they are actually unneeded.

A related problem is that a lot of ideas people that really should be
discussed somehow get dropped into a ticket without discussion.

> - I also think we should consider this in a larger framework of how we
>   plan the entire release cycle.  Right now we are planning major
>   feature for each release assuming we have full three sprints, and
>   checking the reality with the known and/or expected points of the
>   expected tasks for the features.  I think this process has been
>   working quite well recently.  But if we intend to use the last
>   sprint of a release cycle for "hardening", we should revise the
>   planning math: we basically need to assume we have a two-sprint
>   window, and we can only plan features that can be done within that
>   narrower period.  This means we'll be able to include fewer features
>   in future releases (which will also recursively affect much longer
>   plans such as yearly ones).  I think it's actually a good thing than
>   prioritizing too many immature features, leaving ticking bombs in
>   the code, but we need to expect that (for that reason, I'm less
>   positive about doing it for this release cycle).

I agree that we should consider this in the larger framework. 

We don't tend to have too many tasks associated with a release. This is
probably because our current release is sort of SNAPSHOT++ of our code:
Jeremy makes a branch and does a little additional testing and updates
missing documentation, but we don't have the traditional ISC
alpha/beta/RC phases. Even if we did, I don't think  our "hardening"
sprints would really be release related, and probably be more like
"tidying" sprints.

We have many possibilities here:

* We could indeed do 2 normal sprints and 1 hardening sprint per
  release. As you suggest, that means fewer features per release.
* We could add a shorter, 1-week, sprint for tidying. So we would make
  a release every 7 weeks instead of every 6 weeks. I tend to think that
  this is a bad idea because that is a very short amount of time, and
  also because it breaks our normal sprint pacing.
* We could simply add an additional hardening sprint, so 3 normal
  sprints and 1 hardening sprint, making a release every 8 weeks.
* We could also add hardening sprints on an "as needed" basis. My
  reasons for suggesting this is that I think if we spend 33% or 20%
  or 25% of our time doing cleanup that we'll end up burning down the
  backlog very quickly. People tend to like predictable release
  schedules though, so saying "we might throw in an extra sprint or
  not" is probably annoying, and it is probably better if we say "any
  outstanding issues will get done in this sprint, and if we have time
  we can do some other work".

My personal preference is for the 3+1 approach, making a release every
8 weeks.

If we divide Y4 into 3 mostly equal time periods (usability, resolver,
and DNSSEC management), then we would have 2 releases per focus area.
We could possibly aim for making 3 "real" releases in Y4 as well, which
go through the normal alpha/beta/RC cycle. This could mean targeting
2012-08-01 as the date for bind-10.0-alpha1, which would be usable for
authoritative-only operators. 

Cheers,

--
Shan