Re: Discussing issues

[Egbert Eich <eich@XFree86.Org>]

Havoc Pennington writes:
 > 
 > Great, so let's design a third outcome.
 > 
 > Strawman proposal: we create a fairly open infrastructure/process
 > (quite a few people with commit access to *their own module* and the
 > web site for their own module, ability to create mailing lists of
 > their choice for their module, ability to create bugzilla components
 > for their module). This infrastructure hosts N modules, some of which
 > are currently under XFree86. Anybody who touches stuff outside of
 > their module without asking gets publicly flamed/warned zero-to-N
 > times and then loses commit access for N to infinite months.
 > Depending on flagrancy of the action.
 > 
 > Module maintainers are dictators for their module. However, some
 > subsets of module maintainers work together to build releases.  For
 > example, the driver maintainers might get together and build a driver
 > release. The people working on XFree86 might get together and build a
 > traditionally-scoped X distribution. These releases are done with the
 > buy-in of the maintainers who retain control of their own modules.

I'd even go as far as each maintainer should decide to release his
driver as needed.
The least common denominator should be the full release that should
ship the latest stable version of the driver.

 > 
 > Releases are "governed" in whatever way the module maintainers
 > involved in that release want to govern them. So for example if 
 > the current XFree86 core team wants to release the modules that they
 > own, then they would be the sole government of that release.
 > 
 > The initial list of module maintainers would be the people currently
 > recognized as maintainers of each area. If someone wants to change
 > something in ways the maintainer doesn't like, they have to create
 > their own module to play in, or ask maintainer permission to create a
 > branch.
 > 
 > For blessing/standardizing/coordinating/whatever new features, the
 > first guideline is simply that if you want something to be part of X,
 > it should be hosted in this infrastructure. So the STSF guys would
 > have seen fontconfig land in CVS as soon as it got off the ground, and
 > vice versa.
 > 
 > The "blessing" of something like STSF or fontconfig would happen by
 > those modules being included in multi-module releases. As long as they
 > aren't in a release, they would not be blessed in any way, and
 > regardless of release inclusion both would be allowed to use the
 > hosting infrastructure.
 > 
 > To initially populate the infrastructure, we'd import XFree86,
 > freedesktop.org, STSF, and other interesting projects.  The barrier to
 > entry for importing new projects would be low but nonzero; it would
 > just have to seem to belong to the X umbrella more than any other
 > umbrella.
 > 

OK. If you want to import XFree86 I'd request to leave the main CVS
- that's the one where the commits go to - where it is now. You can 
and should however 'mirror' the XFree86 CVS regularly. The
infrastructure to do so is in place already:
cvsupd is up and running and you should run cvsup regularly to resync
the tree.

Egbert.
_______________________________________________
Forum mailing list
Forum@XFree86.Org
http://XFree86.Org/mailman/listinfo/forum