[bind10-dev] Quality of in-memory code

Michal 'vorner' Vaner michal.vaner at nic.cz
Wed Feb 6 09:15:04 UTC 2013


Hello

This is one old email :-O. I don't even remember the issues I was referring
then.

On Tue, Feb 05, 2013 at 11:11:12AM -0800, JINMEI Tatuya / 神明達哉 wrote:
> This seems to be quite a high level discussion, so opinions may
> naturally vary, but I personally don't think the quality of the new
> in-memory data source implementation is that low.  They are generally
> and IMO reasonably modularized, well tested and documented, and each
> method is reasonably concise and understandable (but it's also quite
> possible that I'm biased because I was deeply involved in the design
> and implementation, and I proposed many specific parts of it).

AFAIK I wasn't really implying it was crashing or something. It was mostly that
bits are missing and the interface is not comfortable to use.

> I remember we discussed these pros and cons, probably in a different
> context, before, and in my memory our general consensus is to keep the
> multi-developer style with understanding and accepting its cost.

I'm not against multi-developer.

But I think we did say we would have some post-design review and call and I
don't think this happened for few last major features. Should we try to do
something about it? Are we planning a new feature soon?

> - fix more details in the design phase to minimize open points before
>   the implementation phase.  I personally think this is not really
>   good, because often we cannot be sure about some details until we
>   actually implement, test and use it

I too think this wouldn't work.

> - have more communication to clarify the points during the
>   implementation phase.  I think we already do this, but it's probably
>   not sufficient.

That may be an option. But I guess it's not because it would be unclear during
the implementation phase. It's just clear to different people in different ways.

> - have some post-complete fix phase to review the entire design and
>   interface and fix obvious glitches.  That's probably one thing we
>   are not doing well right now - in many cases we run out of time just
>   to complete a feature, followed by another new feature.  We
>   introduced a concept of "hardening sprint", but I'm afraid it's not
>   working as we hoped (actually we've even skipped it for quite some
>   time).  I think this is something we can improve right now.

Yes, this could help. Or someone (probably the person who made the design) could
keep an eye during the implementation. Not a real review, just a quick look at
each branch or something.

With regards

-- 
grep me no patterns and I'll tell you no lines.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130206/cd9d3658/attachment.bin>


More information about the bind10-dev mailing list