Adding new modules to CVS and future modular releases

[Adam Jackson]

On Wednesday 04 January 2006 16:12, Alan Coopersmith wrote:
> The addition of the glxcompmgr to the Xorg modular CVS recently raises
> a question about what modules should be added going forward.
>
> In this case, glxcompmgr seems obvious as something that should be hosted
> in Xorg CVS, but not everything people may want to add may be so clear cut.
> For instance, we pulled pclcomp shortly before release - if the license
> issues were cleared up, should it be included directly in Xorg CVS/releases
> or just become another one of the external dependencies, since it's really
> not X related, even if Xprint happens to use it when generated PCL output?

I think the latter; I'll cover this in more detail in a second.

> What rules do we want to use going forward?   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" ?

I'm all for this ;)

> Do we want different 
> criteria for CVS hosting vs. including in the release?

I think we do, but I'm not completely clear yet on what those criteria are.

One extreme would be to just drop everything from app/ from "the release", and 
set them free on their own release schedules.  Since some of those apps are 
nearly essential for using the server, xhost and xauth to name two, this is 
probably a hostile stance to take.  The other extreme is to let any X client 
that comes along into both CVS and the release.  This is also undesirable for 
fairly obvious reasons.

Broadly speaking I think there's four classes of apps in app/:

1: Essential tools with no replacement in the DEs (xdpyinfo, xhost)
2: Useful projects that may have counterparts in the DE (xdm, twm)
3: Technology demos with little practical application (xdbedizzy, xeyes)
4: Antiquated functionality useful for legacy systems (mkcfm, lbxproxy)

I would draw the line at about 1.5 for the release, meaning, all of category 1 
and some of category 2.  The pieces from category 2 I would include would be 
things that are either experimental and therefore might not have counterparts 
in all DEs yet - glxcompmgr, for example - or those that are widely adopted.  
And in general if there's debate about whether a component should be included 
in that 1.5, include it.

I'd be much less strict about CVS hosting, that's basically free and has 
pretty low overhead both from the administrative and release management 
perspectives.

> 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?

To the extent that they're willing to maintain it, sure.  If it's just "hey 
let's import uwm for fun" then that's not particularly useful.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-arch/attachments/20060109/0971b158/attachment.pgp