Thoughts and a possible plan

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On March 10, 2004 05:13, Mike Hearn wrote:
> B) It should use time-based releases

why? what benefit does this bring, exactly, besides impose artificial barriers 
to ensuring the included software is actually ready? release when its ready 
and set reasonable feature and time goals from the start; this works for the 
vast majority of open source projects quite nicely and helps improve quality 
by removing the pressure of artificial deadlines. projects that have trouble 
figuring out release schedules may find time based releases useful as a 
matter of self-discipline, but i don't see it as broadly useful.

> C) It should *not* try and do an LSB and specify the
> behaviours/APIs/ABIs of the components in DocBook SGML.

this should be something each individual project does for its software and 
maintains, yes.

> D) It should provide an easy way for users to get the platform on their
> system and then update to the latest versions, even on older distros.

i don't see that as the job of FD.o, nor something reasonable to expect.

> D is clearly something best done by volunteers by preparing apt/yum
> repositories, maintaining the (virtual) packages in their distros
> archives and so on. The idea is to be able to do "apt-get install
> platform-1.2" and have all the necessary libraries installed and
> upgraded even on non-current distros.

... and conflict with official OS vendor binaries, have nascent technical 
support, etc ... i just don't agree with this.

> E) It should have one or at most two maintainers who's word on what goes
> in and stays out is final, for sanity's sake. Maintainers can override
> policy if a good enough precedent is given.

i'm not sure what you mean by "maintainer" really. if you mean "someone who 
oversees the release schedule and maintains adherence to that schedule and 
it's attendant aims" i would agree; if you mean someone who architects what 
the platform is as a whole, i wouldn't.

> F) It should be libtool-style versioned. IE the platform is "1.0", then
> "1.1" which means all software in the platform is backwards compatible,
> then one day it breaks backwards compat (but remains parallel
> installable) and becomes platform 2.0

common sense...

> WHAT: Software in the platform should do a major release at max 1 month
> prior to the release of the platform OR Software in the platform should
> synchronize release cycles with the platform.
>
> WHY: The primary aim of the platform is to reduce dependencies. If
> software does not sync its release cycles with the platform, it's
> possible a sparkly new version of FooLib will come out a week after the
> platform is finalised. Software using FooLib will then depend on not
> just the platform but also the newest version of FooLib because the
> users want the new features it makes available. We failed to meet our
> goal of minimizing discrete dependencies.

yes and no. people shouldn't developer for "newer versions" of components if 
they are wanting to develop against a stable platform release. but i don't 
see how this should become a reason to hamstring individual projects?

> WHAT: Software in the platform should not break interface stability
> until the platform as a whole does.

i think this generally makes sense, though it will mean a good amount of 
effort in intra-project coordination...

> WHAT: Software in the platform should be parallel installable.

yes; this is easy to accomplish.

> EXTRA: this technique is new but trivial, see
> http://ometer.com/parallel.html for details

"new" as in "years and years old new" ;-)

> WHAT: Software in the platform should be LGPL or X11 licensed (or
> equivalents)
>
> WHY: Usage of the platform should not attempt to enforce particular
> licensing on the users. This is especially important for achieving the
> second stated goal, which is to make Linux more hospitable for
> proprietary software. That means GPLd libs are not acceptable.

i don't agree. if someone wishes to use the platform and there is a GPL'd 
library, the don't have to use it. simple as that. _Free_ desktop dot org, 
not _Proprietary_ desktop dot org.

> EXTRA: As with all platform policy the maintainers word is final and
> exceptions are allowed if deemed useful. For instance, it may be decided
> that allowing Qt is acceptable because of the dual license.

i think Qt is a moot issue, see below when you get to listing libs.

> Other random things - you may have noticed I use the name Linux
> liberally throughout this email. Given that all other forms of UNIX have
> single, centralised dependency archives and little to no third party
> packaging activity, I don't think it'd be useful for say FreeBSD or AIX.

what would this gain, besides less users and less projects using the platform?
e.g. this makes it rather less useful for projects like KDE who happen to care 
about cross platform development and support. AFAIC, FD.o is not about 
creating a distro, it's about creating a set of software. or have i 
completely misunderstood the purpose of this exercise? 

> Win32 portability is not an interesting goal at this time.

i thought you wanted to support closed source software? ;-P

> * Inclusion of a very small set of libs. Basically what you need to do a
> basic desktop app and no more. Other software can be added later once
> they have brought themselves into line with project policy. My hotlist
> would be:
>  	* GTK+

no appropriate IMHO. FD.o is about the layer BENEATH Gtk+/Qt/etc such that we 
can all build on a COMMON foundation from there up.

> 	* Some version of xlibs

useful

> 	* glibc 2.2.x
> 		[ features new in mainline glibc 2.3 are not interesting
> 		  for desktop apps, and the new threading models are not
> 		  universally available on all distros yet ]

you ARE kidding right? you want an easily installable glibc version people can 
plop as a third party package on their OS? why don't we just create a whole 
OS while we're at it? no, this is not useful at all...

> 	* C++ support <- there are *still* gcc ABI breaks going on but
> 	  fortunately only at the edges, we could prolly afford to
> 	  ignore them

what does C++ support mean, exactly? and why C++ but not Python, etc? do you 
mean C++ bindings to Gtk+? if so, i think that's as irrelevant as Gtk+ 
itself.

> Yes, Qt is not there. One widget toolkit is enough to start with. Qt

no it isn't. especially since MANY of the people involved in FD.o are people 
with KDE interests, including Daniel. in fact, Gtk+ is one toolkit too many. 
there already is the GNOME project, perhaps that's what you are looking for. 
the purpose of FD.o is not at that height in the software stack, but lower 
and to provide technologies to bind the projects together, not further 
segment and fragment the picture.

i think you completley miss the point of this whole venture.

> DBUS is not there. This is a key point of disagreement between me and
> Daniel. I don't see DBUS as being critical for building desktop apps.

ROFL.. so we need a widget set, but not a common IPC mechanism? ludicrous. 
this is one of THE most important things FD.o can bring to the table as it is 
a vital lynch pin between the kernel, non-GUI apps and the plethora of 
desktop apps that all NEED to communicate and only do so in a patchwork (at 
best) way right now.

> While I agree it should probably find its way in there eventually I
> think it should be treated the same as any other piece of software - if
> the maintainer is willing to work and a good case is made, it should be
> included.

why release the platform w/out it? why not get DBUS into a releasable state 
and include it?

> KDE and Gnome libraries would typically not be included. There seems
> little point - KDE and Gnome are already platforms, if a project wishes
> to depend on them then great. For whatever reasons (politics,
> portability, dependency sizes, history) there is a great deal of
> software out there which is not KDE nor Gnome. These are the programs at
> which an FDO platform could/should target.

FD.o should target KDE and GNOME. look at the people involved if you wonder 
why, look at what created the need and desire for FD.o if you're still 
wondering.

> Schedule - has to start somewhere. The most easily identifiable natural
> "rhythm" currently is GNOME/Fedora,

what is natural to you is completely irrelevant to many others. again, why a 
time based release? how does this help anything?


- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
while (!horse()); cart();
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQFAT8HV1rcusafx20MRAvQFAJ9Ug/pOa81xJSQWoqtpf2bpUlNFmwCgmg6Y
qngfJrpZ/l8LUJYsll61i1s=
=Qcju
-----END PGP SIGNATURE-----