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?
There are very few people in the NetBSD community who don't complain about how long it is between releases; this sort of thing is EXACTLY what delays releases and discourages release engineers. People have to take responsibility for acting in a timely fashion. If it's an important issue, and you've noticed it - push it to resolution NOW, and please don't wait until it's screwing up other people's stuff.
As you can tell, I'm very frustrated, and feel like a large segment of the developer population does not respect releng's time and effort. I'm sorry if this rant feels personally pointed at any one person, I'm certainly not intending it that way. However, any release is going to have bugs - some of them are likely to be the sorts of things we have to deal with for years. There comes a point where you just have to say, "I'm sorry, it's too late". If consensus can be reached, we can fix the documentation for the release to deprecate the current state of things, and give users of the library a heads up that we feel there is a design flaw that we intend to address - but changing it *now*? Madness.
+j