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

[Roland McGrath <roland at redhat dot com>]

> Is this a new policy?  The current glibc sources certainly contain a
> number of ports that I would consider "non-mainstream".  Are they going
> to be removed in future releases?  Who decides when an architecture
> becomes mainstream?  Can you explain how this works?

In the past we have not had any formal policy on this.  We have not
before articulated the full policy we now have in mind.  What Ulrich
said was correct, but did not elaborate on the rationale and methodology
very much.  I'll try to make it more clear now.

The policy is that the main glibc source tree actively maintained by the
core glibc developers should contain only the ports that are maintained
by people actively involved in glibc development on a daily basis.
There is a central maintenance cost associated with each port that
resides in the main source tree.  The intent of the policy is to keep
the maintenance burden of each port on those who benefit from and care
about it.  Each of the active glibc developers has some ports that he is
particularly interested in (or responsible for in his job), and for
those the core developers as a group are willing to share collectively
some of those burdens of other developers' pet ports in appreciation of
the overall collective benefit of those other developers' daily
contributions.  In other cases, we are not willing the shoulder that
burden--if your contributions only benefit the community of Xtensa users
and we and the larger community we care for are not among them, then we
are not volunteering any efforts that are specifically in your aid.
That's the way freedom works.

We are not trying to give you a hard time, nor discourage you from
contributing.  If you want to be actively involved in glibc development,
then jump right on in!  Bugzilla has plenty of items that can use
attention, if you are looking for something to help with.  If your only
interest is in maintaining your port, then that is fine too; your time
is yours to allocate, just like ours is ours.  The distinction of an
"add-on" vs a port in the main source tree is mostly a meaningless
implementation detail.  We are not declaring such architectures "second
class".  We don't make those rankings, the users do by their daily
hardware choices.  It's simply a distinction of what we, the core glibc
developers, are spending time on and what we are not.  The main reason
we want to be so conservative about what ports to include in the main
source tree is that it's in fact so easy for us to separate them to ease
central maintenance without making the separated ports themselves harder
to maintain.

The distinction I made is "maintained by people involved on a daily
basis" or not.  If once in a while you fetch some glibc snapshot and
update your port, then you are not involved at all.  If once a week you
cvs update and check for bit rot in your port, you are not an active
contributor.  That latter case might be good enough to be a low burden,
but it is not motivational to including your port in the main source
tree where some of the burden for it falls on the rest of us.  I'm not
saying this is a closed club--it's certainly not.  But you can't just
show up with your port and expect to get in.  Even if you are staying on
top of development with a keen eye and keeping your port current minute
by minute whenever Ulrich posts to libc-hacker saying, "I made some
changes and most architectures will need some updates right away," if
all you do is fix your own port then we have little motivation to
shoulder the fundamental burdens just of having it reside in the same
repository.

The question of copyright ownership and of the general notion of
contribution to Project GNU is really a separate one from how we slice
up the glibc source tree and the maintenance responsibility for its
pieces.  The FSF chose the LGPL terms for libc, so that tells us that
what the FSF would like is for you to have the freedom to choose either
to collaborate directly or to share your changes with those who want
them without asking them, us, or anyone else how to go about it.  If you
would like to assign the copyright on your port to the FSF, then bully
for you!  That's what I'd do too, and I would feel good about doing it.
If all the copyrights are kosher, then the FSF would be happy to have
your code distributed on ftp.gnu.org; all it takes is some paying
attention to what's shaking in libc hacking and you can easily
coordinate with me and other glibc developers to get your bits where
they need to go and mentioned in announcements and so forth.  If you'd
like the source repository for your port to be in a public place for
open collaboration, then you can do that too--any company can host
servers to aid the community of developers who want to work on that
code; or you can easily put this on Savannah (and you might think about
contributing some resources/money to share the burden of those already
contributing the server resources for free projects that benefit you).

It's important to realize that keeping track of contributors, specific
contributions, and copyright assignment status, is a significant
maintenance burden itself.  For the main glibc source tree, we as the
core glibc developers are responsible for making sure all contributions
are kosher under the FSF's procedures.  I and each other maintainer have
a personal obligation to the GNU Project to do this diligently, not just
for the one big port contribution where you've already done the
paperwork, but for every future contribution of any kind from Xtensa
developers and users.  Diligence requires checking everything closely,
not just taking your or anyone else's word on things; we take this
seriously, and it can be lot of work (scattered in chunks to arrive at
unknown times throughout the future).  We don't want that burden.  If
you maintain your port separately then it's not our problem.  I'm glad
you intend to assign copyright to the FSF.  Having done so you will have
an obligation to be diligent in doing the paperwork for future changes
you incorporate from the community and your own employees.  If you fall
down on the job, I personally will be disappointed, but you will have a
problem with the FSF and not with me.  Neither I nor any other glibc
developer will be spending any time in the middle of such a debacle
should one ensue.  I'm not suggesting I doubt your good faith on these
matters, but they are quite easy to mess up and potentially very
difficult to fix later--and my trust in good faith is, to be frank, due
solely to my renowned sunny disposition, as I'd never heard of any of
you before this week.  Moreover, even done perfectly they are some
burden on those responsible for ensuring diligence in their handling.

> I'm sure Joe is willing to maintain the Xtensa port of glibc, so there
> should be minimal effort required by the core glibc developers,
> especially since the port-specific code can be so nicely separated.

You have hit the nail on the head.  There should be minimal effort required
by the core glibc developers--in fact, we demand it.  Since the
port-specific code can be so nicely separated, it is easy for Joe to
maintain the Xtensa port in the way we've told you meets this requirement.

Maintaining a port as an add-on you can be as active as you want to be.
If you track glibc cvs every day and keep your add-on source tree in
perfect working order, then great!  People helping in your port's
development can just run two cvs update commands before they rebuild.

> Xtensa users and partners will certainly prefer to have the Xtensa port
> included in the main glibc sources.  

glibc users would prefer to have glibc's primary development resources
directed to where they help the most users, and to have anyone who is
benefitting from those development efforts give back to the glibc community
by making contributions that benefit everyone.

> Why do you want to reject contributions for new architectures?

We aren't rejecting your contributions.  Some ways of "contributing" in
fact take from others like us who are already sharing our work with you,
but don't give anything back that actually benefits our community.  We
are telling you how to go about sharing what you have with those it
benefits in a way that won't have that effect.



Thanks,
Roland