--pgp-sign-Multipart_Mon_Dec_12_09:44:06_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "pb" == Paul Brook <paul@codesourcery.com> writes:

    pb> The only way to avoid that is to provide the resources
    pb> (ie. programmers or money to hire programmers) to maintain
    pb> support for the "older stuff". whining just irritates the
    pb> people you want to help you :-)

yeah, uh, and of course NetBSD developers wouldn't have any kind of
interesting perspective, experience, or even ADVICE, on what source
code architecture accomplishes this most efficiently since they don't
bang up against this issue in their daily work very much compared to,
oh, gcc or Linux developers.

The rule you're forgetting is that, if Developer A is using part of a
project and Developer B's changes keep introducing regressions in it,
then Developer A ends up spending most of his time cleaning up these
problems instead of working on what interests him.  The typical open
source response of ``well, if you want it to work, then why don't you
fix it yourself?  I'm not your employee, so you can't tell me what to
do,'' is totally inappropriate in this case.  In this scenario,
Developer B has effectively hired Developer A for $0/hr, and hired him
to do the messy work Developer B doesn't want to do.  Developer A just
wants it to work like it did yesterday.  This is the scenario that
causes projects to fork.

gcc in NetBSD until recently was effectively a fork, and for the
reasons above---we shipped old versions with huge amounts of local
patches to keep all the architectures we support working up to useable
standards compared to their status in the gcc mainline.  It took a
major evangelical push to start being better neighbors and thinking
more long-term, and getting NetBSD guys to push these local NetBSD
patches back up to gcc, and to start using our dist/ Makefile
framework so it's easier to import gcc more frequently.  I don't see
how it would remain practical to do this if the gcc position is, ``gcc
should work for our new task.  Those who want to use it for other
tasks for which gcc already works should provide staff to maintain the
old functionality.''  

I don't understand the coldfire issue at all, and it could easily be
that Paul is right for some other better reason than his offensive
``the only way is for you to provide resources to fix what I break.''
But, if what we're talking about is avoiding bitrot of the m68k
target, NetBSD, AFAICT, is committed to making formal releases where
all the ports work, or removing the ports.  I'd expect gcc to do the
same.  It's not a matter of staffing---it's a matter of not allowing
short-term vested interests to dictate an architecture and a
responsibility-ethic that's unmaintainable for all of the many other
diverse people using the currently-working codebase, now and in the
future.  This means that, if someone wants to add some new shiny thing
that everyone else also thinks is shiny, but the guy is not willing to
do it in a way that avoids regressions, then the _new_ thing goes on
the fork, and shiny-thing developer guy gets to do the work of porting
all the MI gcc improvements to his fork forever, or else do his work
in a way that is less convenient but passes review and is minimally
regression-prone and maximizes code-sharing.  The alternative is to
release a codebase that claims to work for old and strange
architectures and doesn't, like the Linux kernel.  This can and has
been taken to what I feel is absurdity, like NetBSD and ALTQ, but
that's the rule that works and seems only fair to me.

--pgp-sign-Multipart_Mon_Dec_12_09:44:06_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iQCVAwUAQ52MtonCBbTaW/4dAQLmFAP+J2iwu1bY2dK1XxkVYjg8WER28kk0VJnW
oRySwrLiszrynTFd5/rU+YZqtclK/a7kiWvtHMisPoNITh+kxOEKkI3nMgR8uqZa
93yJoxk1hXhjRzPpqh8kfRNcOFARNYVFXNtPSMkv7/OD5H5/0tOfy5tpLoD4UOKj
nFSDQuPIv84=
=fFwU
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Dec_12_09:44:06_2005-1--