Re: rb_tree_iterate(3) documentation vs. implementation

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Wed, Aug 29, 2012 at 09:48:45AM -0700, Jeff Rizzo wrote:
> On 8/29/12 9:31 AM, Thor Lancelot Simon wrote:
> >On Wed, Aug 29, 2012 at 09:11:34AM -0700, Jeff Rizzo wrote:
> >>On 8/28/12 11:12 AM, Paul Goyette wrote:
> >>>On Tue, 28 Aug 2012, Mindaugas Rasiukevicius wrote:
> >>>
> >>>>- There is also PR/45893.  The reason why these changes were not
> >>>>made are
> >>>>concerns about breaking backwards compatibility (apparently, there are
> >>>>3rd party users of this library already).  In theory, it is not
> >>>>too late,
> >>>>as netbsd-6 will be the first release shipping rbtree(3), but
> >>>>we need to
> >>>>reach the consensus on this.
> >>>Seems to me, we ought to get this "right" before we formally ship.
> >>>The "early adopters" who are already using rbtree(3) already
> >>>should be few in number and hopefully we could work with them to
> >>>adapt to the changes.
> >>>
> >>Why is it that people still think that at this late date, we would
> >>entertain changing an API in NetBSD-6 when a release candidate is
> >>built and about to be announced?!?
>
> >Because this is a very serious API bug, and it might be preferable to
> >never ship a version of NetBSD that has it, rather than have to support
> >two APIs (broken and non-broken) forever?
> 
> I will point out that this "very serious API bug" has been known
> about since BEFORE the netbsd-6 branch;  if it was not worth the
> time of those who care about this API to have done something about
> it in the months since then, why does it suddenly get to percolate
> to the top of priorities now, when it would hold up the release and
> impact *my* (and other release engineers') work?

Because someone who did not know about it since BEFORE the netbsd-6
branch pointed it out publically and a larger population of developers
realized it's a significant problem?

You're the release engineer.  Go ahead, make a decision.  Nobody's saying
it's not up to you: plainly, it is.

But, even though clearly there was a screwup in not bringing this
problem to releng's attention (by checking in a fix and submitting a
pullup request) on the part of the people who originally noticed it, I
would advocate that the burden of ongoing maintenance if this is left
how it is might well outweigh the delay it causes to the release, if
it is changed at this late date.

Thor