[forum] Consensus Building

[Paul de Vrieze]

--Boundary-02=_PEVi+Prltit0LVm
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

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 poi=
nt=20
where something is missing from X. Then they implement the necesarry parts =
as=20
an extension after which X.org says it is an official X extension. This=20
compared to the approach where X.org sees a need for an extension. It desig=
ns=20
the extension, and all X providers are going to implement the extension=20
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=
=20
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=20
is very well possible. Of course this doesn't hold in all cases, but that a=
re=20
implementation details.

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

Thanks for your work

Paul

=2D-=20
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

--Boundary-02=_PEVi+Prltit0LVm
Content-Type: application/pgp-signature
Content-Description: signature

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

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

--Boundary-02=_PEVi+Prltit0LVm--