[bind10-dev] [sprint planning] Estimate discussion for sprint ending 2012-11-06

[JINMEI Tatuya / 神明達哉]

At Mon, 22 Oct 2012 12:48:21 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > Let me take 'lowest and highest are more than 2 position away in the
> > range 1,2,3,5,8,13' as a guideline. There is only one ticket that
> > matches that:
> > 
> > #2367 (select features to build and install): lowest 3, hightest 13, and
> > one not-estimated because the ticket does not really specify specific tasks
> 
> Here, I'd guess some people are cautious, for two reasons:
>  • It's bunch of autoconf and makefiles. I'm not sure about others, but I always
>    find the thing bites, mostly due to huge number of non-transparent layers of
>    macro expansions and unclear semantics.
>  • There might be hidden problems with dependencies, conditional compilation,
>    parts of system tests might start failing, etc.
> 
> I think the task might prove simple (but would take some time to decide about
> each of the directories if it should be compiled or not) or it might turn to be
> a huge amount of work hunting something unexpected.

I generally agree.  I'd also point out that by nature it can hit
portability issues on different systems, which are generally time
consuming even if technically not difficult.  Whatever the specific
task(s) is, in my gut feeling it cannot be that small like "3".

> > There are a few comments that may warrant a bit of discussion as well:
> > 
> > #2377 (define dns::MasterLoad class): should we divide this one further?
> 
> I don't know. There's some example code and it doesn't seem that much
> complicated. Also, where to cut into smaller tasks? If we cut the tasks too
> much, they stop making sense and we waste time trying to guess what should be
> done there (I think #2207 could be an example ‒ very simple class, but without
> knowledge of the surrounding rest, it's hard to know what it should do).

One possibility is to defer the case where we have "initial white
space" indicating using the same owner name.  We could also defer some
of post construction checks like the one for SOA.  And also for error
handling (in which case the initial version only works for valid
formats).

The entire work may not be that big, but the first task of a new class
implementation normally requires a larger amount of time because of
some level of design consideration, test setup, adding general
documentation.  That's why I thought it might make sense to separate
it into two tasks.

But I'm not so sure about it either.  I think I can live with a single
ticket for all of these, but in that case I think it's safe to give it
a relatively higher pint (I'd say at least 8).

> > #2380 (revise b10-loadzone using datasrc.ZoneLoader): should we divide
> > this one further?
> 
> Does anybody have an idea how to split it? Maybe suggest that whoever takes the
> task could create sub-tasks if they make sense?

I don't have a very specific plan, but, similar to the `MasterLoader`
case above, we may be able to begin with a runnable but very simple
version, skipping error handling for example, in the initial task.

> And, will there be anything left of the current b10-loadzone after the rewrite?

Do you mean whether there will be a feature that exists in the current
loadzone but not in new one?  There will some.  The very initial
version will inherit all limitations of the initial version of the
underlying `MasterLoader`, so we won't support "$" directives or
flexible ordering/omissions of TTL/CLASS/TYPE.  Until we support
these, we won't actually be able to "replace" the current loadzone;
I guess two versions will coexist for some period.

Also, it will be tricker to show progress of loading even in a more
complete version.  We should probably think about how to realize that
in the new framework.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.