Re: Consensus Building

On Tuesday 01 April 2003 10:32, Egbert Eich wrote:
> Biju Chacko writes:
>  > Firstly, with regard to X.org function:
>  >
>  > * Is it agreed that X.org (or an alternative standards body) should
>  > stick to certifying innovations from downstream X implementations as
>  > standards and that it should not be generating new extensions to the
>  > standard itself?
>
> Extensions are the way to add innovations to X. There is a
> standarized procedure to add extensions. You are probably referring
> to the X Core Protocol. Yes, we must avoid touching this.
> A more interesting question is how far should an extension
> be standardized before we add it to a release.
> Since an extension is client visible we have created a
> de-facto standard once clients start using it.

I think he means that the process goes in a way that some people find a point 
where something is missing from X. Then they implement the necesarry parts as 
an extension after which X.org says it is an official X extension. This 
compared to the approach where X.org sees a need for an extension. It designs 
the extension, and all X providers are going to implement the extension 
because it is official, but before knowing it works and is useful.

>
>  > Secondly, with regard to the future of XFree86:
>  >
>  > * There does not seem to be serious opposition to the idea that XFree86
>  > should be split into two trees: a stable tree and an unstable tree.
>
> Hm, two trees, two CVS? I don't opt for having two CVS repositories
> as it makes merging a pain. Instead we should use separate branches.
> In fact we have been using separate branches for the forthcoming release
> and for bugfixes for the old release. Unfortunately the bugfix branch
> never got used heavily.
> We should however create more experimental branches. This way
> new features can be made available for testing much easier.
> Once they have stabilized and agreed on merging back to the
> trunk should be no problem.

I guess he meant that, two CVS's is nonsense, and not the consensus of the 
list.
>
> Drivers are about the only kind of modules that can be released
> separately without creating a major maintenance nightmare.
> New features in other modules change (or amend) the ABI.
> Currently we have no decend way to ensure that the ABIs of
> all modules match. We only have the overall ABI version
> number which is the same for every module of a certain
> version of the tree.
>

What about extensions or client libs. Adding fontconfig/Xft-2 to XFree-4.2.1 
is very well possible. Of course this doesn't hold in all cases, but that are 
implementation details.

> And yes, I'm working on separating out the drivers.

Thanks for your work

Paul

-- 
Paul de Vrieze
Researcher
Mail: [email protected]
Homepage: http://www.cs.kun.nl/~pauldv

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+iVEPNb2zbbdIrucRAmEDAKCAIIwxjk57l5AduP8r7h+WZ3OpcwCdE+rk
4ZkN9iHvB78o/2vgVnElNqE=
=k0Uq
-----END PGP SIGNATURE-----