Adding new modules to CVS and future modular releases

[Keith Packard]

On Wed, 2006-01-04 at 13:12 -0800, Alan Coopersmith wrote:

> What rules do we want to use going forward?  

We've had several discussions about this in the past when it was all
theoretical. I think the criteria we came up with then are still useful
though; X.Org's 'release' should include the bits needed to use X within
a modern operating system release, and I think ajax's cut point is just
about right (if too low). 

That is, if it hasn't been changed in a long time because no-one is
actually using it, we shouldn't ship it. Making this cut relatively deep
at first will provide for some community feed-back pretty quickly after
the release. We've got one big chance to dramatically reduce our
workload; let's take advantage of it.

Even if we do get people to complain bitterly about missing xditview, we
can offer to let them maintain it within X.Org CVS and let them perform
releases separately from the main X.Org release. But, those decisions
can only be made once we determine which pieces are useful to many
people and yet not really part of our 'platform'.
 
>  Do we need set criteria or a
> simple "Ask the release manager - if they think it's obvious, they say yes,
> if not, they send on to xorg-modular or xorg-arch" ?   Do we want different
> criteria for CVS hosting vs. including in the release?

Yeah, we've always said that CVS hosting and release are different
beasts; the main reason being that it's easy to include/exclude things
from CVS from the release but a pain to migrate projects to different
CVS hosting.

>    Should we allow
> anyone who wants to maintain one of the old X.org contrib programs to have
> CVS space even if it's not something we'd formally consider part of the
> rollup releases?

Of course, one thing we do want to make clear is that CVS *isn't* the
same as the release any longer. I think we need to get some resources
focused on creating a tractable version of jhbuild (or other) meta build
system so building from CVS will be possible by mere mortals, and that
this build will contain precisely what our release contains.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-arch/attachments/20060111/b4db087e/attachment.pgp