Re: How to submit large patch for xtensa-linux?

[Michael Eager <eager at mvista dot com>]

Roland McGrath wrote:
> > Code which is in the source tree has a higher probabilty of beeing
> > maintained and compatible with other changes, while sources stored
> > elsewhere will inevitably become out of date.
>
>
> We have made the same observation.  What this really means is that by
> putting something in the main source tree, you can get the primary
> maintainers to do a significant amount of maintenance for you.  We know
> we are suckers in this way, we can't help scouring around for bit rot
> from time to time.  But we are trying to stop being doormats for people
> who don't want to maintain their contributions, and in fact wind up just
> sucking our efforts without doing anything that helps our own lives.  
>
> If it's truly inevitable that sources stored elsewhere will become out
> of date, that tells us that noone else claiming sole responsibility for
> their work will actually maintain it with high quality efforts.  If that
> were the case, it would be a very sad state for users of anything that
> we few people don't happen to have chosen to work on.  Such an
> inevitability just strikes me as implausible.  Code is well-supported
> when there are developers who care enough to support it and users who
> care enough to make sure someone has the resources to do so.  We are not
> introducing barriers preventing someone from doing a good job, we are
> just putting up barriers preventing people from enticing us into doing
> their job for them as an inevitable part of doing a good job on what we
> do focus on.  That's right, the problem is that Ulrich Drepper is too
> giving and helpful a person and we have to protect him from himself.
> Shocking but true.

I think you are reading the tea leaves incorrectly.

Changes are frequently made to glibc which are not architecture
specific.  This is the cause of significant amounts of bit rot in
architecture-dependant code, not the lazyness (or absence) of
architecture maintainers.

I have had the task of modifing architecture support patches for one
version of glibc so that they can be applied to a later version.  There
is a barrier which makes this much more difficult, and this barrier will
become higher as more architectures are moved off the mainstream.
This barrier is poor documentation for what changes were made and
how to apply them to other architectures.  One can review a patch
and try to translate the changes made to x86 or ppc into changes for
another architecture, but that can be difficult and unclear.

No one is trying to slough work off on the core maintainers.  They
have plenty to do and it is appreciated.  On the other hand, generic
modifications place a burden on the people who support individual
architectures.

I think that there has to be a better method of ensuring that
architectures are supported rather than the kludge (IMO) of using
add-on and separate files which are not distributed with the core
sources.  My preference is to have sources integrated into the
source tree.  An "add-on" would be my last choice.  If it were a
choice between distributing a patch to glibc which had the same
source file organization versus a patch which created an "add-on"
with a different file organization, my preference would be for the
former.

--
Michael Eager     eager@mvista.com	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085