Depending on external libraries

[Keith Packard]

--==_Exmh_1503486895P
Content-Type: text/plain; charset=us-ascii


Around 10 o'clock on Mar 11, "Kendall Bennett" wrote:

> Assuming that you have somewhere to get an 'upstream' version from that 
> will be correct and work for what you need.

No, jhbuild also allows you to point your configuration at a custom 
version of the package if upstream is really unable (or unwilling) to help 
out.  But frankly, the number of upstream developers unwilling to 
cooperate with X development is vanishingly small; I haven't had a single 
problem getting needed fixes pushed upstream.

> you will potentially have release timing issues with upstream projects
> that can't be solved in time for an official release.

No.  Our dependencies should always be on *released* versions of the 
upstream projects.  If we plan a release assuming the availability of an 
upstream release, then either our release will pend the upstream, or the 
dependency should be revoked.

I don't think we currently have any dependency on non-released versions of 
any of our upstream packages, if so we should fix those.

> Maybe I am biased, but in my experience building a product based on the 
> wxWindows toolkit (now wxWidgets), we had no option *but* to fork the 
> toolkit and maintain our own separate version.

I would take the release history of any upstream project into account when 
selecting what technologies to depend on.  When selecting FreeType as a 
fundemental dependency for client-side fonts on X, I had to look back over 
several years of their development and release history to assure myself 
that they would provide reliable and stable releases.

X.org is also in a different position from a commercial product vendor; we 
can and should expect a reasonable level of cooperation from our upstream 
providers.  Experiences with XFree86 have shown that this works.

> Granted that project needs a serious lesson in release engineering skills,
> but I would hate to have to hold up a release of a new X.org server due to
> political issues with an upstream project.

We can always choose to fork a project which has poor upstream release 
management skills, but I suggest that this should be a last resort for 
technologies which are critical to the window system and for which there 
are no reasonable substitutes.  When we do so, it should be with the 
understanding that X.org now "owns" a release of that project and will 
maintain it going forward separately from the upstream project.

-keith



--==_Exmh_1503486895P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.3.1 11/28/2001

iD8DBQFAULVfQp8BWwlsTdMRAgZBAJ9TWy9aV/E0zkYeYzh6NP2Ll6u9qACdHQT6
Q9kiiHPiA4+mHLkxuYtITCg=
=XWxh
-----END PGP SIGNATURE-----

--==_Exmh_1503486895P--