Linux vs. libio

[Geoff Keating]

> From: Joe Buck <jbuck@synopsys.COM>
> Date: Mon, 20 Dec 99 10:04:02 PST
> 
> Mark Mitchell writes:
> 
> > I assumed that "blanket write privs" applied to everything you get
> > when you do a `cvs co egcs', which includes libio and libstdc++.
> 
> My opinion:
> 
> Blanket write privs are for the purpose of checking things in to CVS.
> Actually doing a release is another matter: for anything that affects
> other projects, the Steering Committee would have to be involved,
> and the SC tries to run by consensus, meaning that if Ulrich Drepper
> were extremely unhappy about something, the SC wouldn't approve its
> release.

My opinion:

The primary purpose of snapshots are for use in the testing and
further development of glibc.  Therefore, it is _not_ a good idea to
break them for no particular reason.  "blanket write privs" only
includes the committing of patches that _work_ (or at least are
believed to work).

> But remember, we never promised that we wouldn't break things in
> *snapshots*.  That's too much of a constraint.

It seems pointless to put stuff in snapshots that will have to be
backed out before a release.

Might I suggest the following flow-chart for Linux GCC ABI changes:

1. Is this patch simply for my internal use only?

   No    Yes------> keep it in your local repository,
   |		    don't put it in CVS at all.  If you think
   |		    others are interested, send it to gcc-patches.
   V
2. Will this patch work on currently shipping Red Hat,
   Debian, Suse, whatever systems, both if you use a new gcc
   on these systems with existing libraries and if you use a new
   gcc to build the libraries but still use old binaries.

   No	 Yes ----->  Then it's probably OK for the mainline tree.
   |
   V
3. Is this patch so important, so useful, that it is acceptable
   to break backwards binary compatibility?

   Yes   No ------>  Then it can't go in, and must be reworked.
   |		     When it's reworked, go back to (2).
   V
4. Can I obtain the consensus of everyone working on or using
   GCC under Linux?

   No    Yes ----->  Budget 1-2 years for building the consensus.  
   |		     Then, once you have that consensus, it can
   |		     go in, at an agreed time, preferably
   |		     with a major version number change for gcc.
   |		     Note that any shared libraries affected
   |		     will also need to bump their version and
   |		     this needs to be coordinated.
   |		     This is a _lot_ of work (budget 50% of
   |		     an engineer/manager's time for the 1-2 years).
   V
5. Your answer at (3) was wrong.
   The patch can't go in, and must be reworked.
   When it's reworked, go back to (2).

-- 
- Geoffrey Keating <geoffk@cygnus.com>