Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

["Alexander N. Kabaev" <ak03 at gte dot com>]

> I still don't see that is a binutils problem. It has been being done
> this way for years in binutils. 

 And doing that for years is exactly what has given binutils the reputation of
the project with very badly maintained _releases_. You seem to suggest that all
interested parties should play weird russian roulette game trying to guess when
binutils CVS HEAD branch is in reasonable shape. The problem with this approach
is that critical bug fixes applied to the tree are getting mixed with other
commits which have potential to introduce new bugs as the new features are being
added to the source. Having bug fixes applied to both -stable and -head branches
elimitates the problem and provides all interested parties with a single place
from where to get source in a _known_ stable state.

BSDs were maintaining -stable and -current branches of their source code
for years now, Linux kernel, KDE, gcc (to some degree) and seemingly every other
major open source software project I can think of are using similar approaches
with remarkable success, binutils being noticeable exception.
 
> All other platforms have been coping with it. My point is if xxxBSDs want
> something in binutils, they have to do the leg work, not expecting the
> binutils developers to do it for them.

No "leg work" done by BSD folks will be able to offset the lack of proper
release management. It is true, all other projects, BSDs included, were able
to cope with the current state of affairs so far, but does that mean there is
no place for improvement?

Just my $.02