Prototype library plan

[Havoc Pennington <hp redhat com>]

Jody Goldberg <jody gnome org> writes:
> This seems like a reasonable proposal.  Do we have a consensus to
> bless it ?  Once accepted we can form a maintenance quorum to
> discuss specifics.

Adding gnome-libs-devel to CC, fixing subject, to be sure everyone has
seen the suggestion.

Here is a more complete writeup, in the form of the README for the new
library.

BTW the library would need an easy-to-sed unique namespace so we can
quickly transfer stuff to other libs. Ideas?

README for libfoo (TODO: s/libfoo/?/):

 This library contains prototype features that are being considered
 for inclusion in one of the stable platform libraries.
 
 The guidelines for this library are:
 
   - All features are intended to end up in a stable platform library
     when they're ready.

   - All features must be "sponsored" by the maintainer of the
     platform library the feature is targetting. Features 
     without sponsors do not go in.

   - In sponsoring a feature, maintainers are saying that think a
     feature along these lines makes sense in their platform library,
     and that the initial implementation looks at least approximately
     like what they want.

   - As soon as a feature has been shipped in stable form in a
     platform library, it comes out of libfoo.

   - If a maintainer decides that a feature doesn't make sense after
     all, or that a radically different approach is required, they can
     "unsponsor" the feature and the feature will be removed from 
     libfoo.

   - All patches must be approved by the sponsor of the feature being
     patched, though the sponsor maintainer may choose to delegate
     patch review duties. (To the person implementing the feature, for
     example.)

   - Maintainers will probably do a final review/revision of features
     before movinng them from prototype library to platform library.

   - Features can only have dependencies that are shared by the target
     platform library. For example you can't use libgnome to implement
     a feature targetted for GLib. (You can however depend on another
     GLib-targetted libfoo feature, of course.)
 
   - Features are in the "foo" namespace not in the platform library
     namespace, and are renamed when they're moved.

   - The API/ABI of libfoo can change at any time, though it's
     courteous to coordinate with app developers, cruft should not be
     left in the prototype library for compatibility reasons.

   - The purpose of this library is to test feature APIs and
     implementations, so the library is expected to be a
     work-in-progress, but bug reports and suggestions are extremely
     welcome.

   - Discussion of features should happen on the mailing list for the
     target platform library, but may also be cc'd to
     gnome-libs-devel gnome org  Coordination of libfoo itself happens
     on gnome-libs-devel gnome org 

   - libfoo will always depend on the latest stable branches of the
     platform libraries, not on the development branches.


We need a volunteer to "maintain" libfoo as a whole, though this
involves just release gruntwork, since patch review is all done by
platform library maintainers.

I'm not sure how "temporary hackarounds" fit in to libfoo;
e.g. EelEllipsizingLabel has a totally different API but the same
function as what will end up in GTK. It'd be kind of nice to put this
sort of stuff in libfoo, perhaps, as long as a replacement for the
hackaround is scheduled for inclusion in the platform library.  We
don't want hacks of indefinite duration in libfoo.

Havoc