How to submit large patch for xtensa-linux?

[Bob Wilson]

Thanks, Roland and Ulrich, for answering my questions.  If I'm interpreting your 
statements correctly, the main issue is that you don't want new, non-mainstream 
architecture ports to be a burden to the core glibc developers.  That makes 
sense to me.

Your proposal to implement the Xtensa port as a glibc add-on might work fine for 
us, but I have some more questions and concerns.

First, for the record, let me say that we're trying to be good citizens of the 
community here.  We're not trying to take advantage of you.  We've written some 
code, and we'd like to contribute that code back to the GNU project.  Such 
contributions benefit the community at large (although not necessarily the core 
glibc developers).  There aren't a lot of Xtensa users out there yet, in 
comparison to some of the mainstream architectures, but the numbers are growing. 
  Contributing the Xtensa port of glibc _will_ benefit the community, albeit a 
small segment of the community, as long as it can be done in a way that doesn't 
place a burden on others.

It would be great if someone from Tensilica could be involved in glibc 
development on a daily basis, but the best we can realistically offer right now 
is to contribute occasional bug fixes and to maintain the Xtensa port so that it 
isn't a burden to anyone else.

So, anyway, here are my questions....

Roland McGrath wrote:
> 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.... [text deleted]
> 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.

This sounds pretty good.  We certainly agree that someone other than the core 
glibc developers will need to take the responsibility to maintain the Xtensa 
port.  Joe Taylor, who wrote almost all of the code, is willing to be the 
maintainer.  I personally don't have a strong opinion on how you slice up the 
source tree.

We've already assigned the copyright for the glibc code we've written to the 
FSF, and this assignment also covers any glibc code that we contribute to glibc 
in the future, so we ought to be OK to have the Xtensa port made available via 
ftp.gnu.org.

So far, so good.  I have two related concerns.

First, despite your intentions that add-on ports will not be "second-class", I 
think that will be the inevitable perception if the add-ons are released 
separately from the main glibc bits.  (Certainly seeing Ulrich's list of 
unmaintained ports that will be made into add-ons makes me think that we will 
suffer from guilt by association.)  You offer to coordinate with us to get our 
bits released -- can we get them included in the main glibc release tarballs?

Second, I'm concerned about possible confusion of users trying to build an 
add-on port.  I haven't seen the details of this add-on mechanism, so maybe this 
concern merely reflects my own uncertainty.  Will extra steps be required by a 
user trying to build glibc for an add-on port?  If so, will the process be kept 
reasonably simple and be well-documented?

It sounds like you folks had pretty much made up your minds to go with this 
add-on approach before we even came along with the Xtensa port, so I suppose 
there's not much chance of getting you to reconsider.  Nevertheless, I'm still a 
bit confused about why it has to be such a burden for you to add a new port when 
someone commits to maintaining it.  My experience maintaining the Xtensa ports 
of GCC and Binutils makes me think it doesn't need to be that way.  (Ulrich, I'm 
not trying to argue that you ought to do it a certain way just because other 
projects do.  I'm merely reflecting my own positive experience with those 
projects.)  In fact, many of the GCC and Binutils developers go out of their way 
to fix up Xtensa-specific code, for example, when changing an interface, but I 
don't expect that of anyone.  I consider it my responsibility to keep the Xtensa 
code working, and I would not object at all if the other developers chose to 
completely ignore the Xtensa code.  Other costs?  You mention the overhead of 
checking contributions, copyright assignments, etc.  Perhaps I'm ignorant of 
what goes on behind the scenes, but my understanding was that by being a 
maintainer of these other GNU projects and accepting cvs-write access, I was 
assuming responsibility for the changes I commit.  Someone had to check 
Tensilica's copyright assignment before granting those privileges, but I assumed 
that was essentially a one-time task.  You also mentioned reviewing patches. 
The other projects I've worked on allow port maintainers to commit patches 
without reviews.

Just in case you're still open to other options, the alternative I would suggest 
is something like the approach used by the GCC project (i.e., accept new ports 
as long as they are actively maintained, drop unmaintained ports, give port 
maintainers the authority and access to make changes without requiring 
intervention from core developers, etc.).  I like this approach, perhaps because 
it is familiar to me, but also because it lets us "little guys" participate in 
GNU projects without imposing a burden on the "big guys".

Any chance you'll consider that option?

--Bob