Thoughts and a possible plan

[Aaron J. Seigo]

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

(no need to CC: me, i'm sub'd =)

On March 11, 2004 09:24, Mike Hearn wrote:
> Even if it's not needed by people who already target pre-existing
> platforms like KDE, GNOME, Java, Mozilla (XUL) or whatever, an
> application being able to say "This program requires Desktop Base 1.2"
> and then be able to rely on the presence of various libraries seems to
> be a step forward from programs having big lists of what they need
> (often expressed in distro-specific terms).

well, they aren't expressed in OS-specific terms for KDE, and there really 
isn't any good reason to do so for any project, really. but in general, i 
agree: having a set of software everyone can use as a foundation that is 
released together Makes Sense(tm).

> In contrast, a collection of software and standards that sits below the
> current platform stacks and helps bind them together (dbus springs to
> mind, there are other examples) could still be called the
> freedesktop.org platform.

exactly. this is what i have always understood freedesktop.org to be.0

> Time based or not really strikes at the core of what makes the base
> different to just a random list of software and versions. Anybody can
> make one of them, I could do it this afternoon, but it wouldn't be
> useful. Why should 3rd party developer A depend on software on this list
> rather than making their own list?

time based or not does not affect the answer to this question. the answer is: 
"because all agree that it's the base". it doesn't matter whether it happens 
every six months, every blue moon or every time the geese migrate north. what 
matters is consensus. the time frame within which that consensus is reached 
is something that affects those developing the components involved, not those 
using / relying on the software.

> * You know the software you're depending on is up to date and modern

that's what version numbers are for. using dates for this is just another form 
of version number.

> * You have some degree of predictability as to when a new platform will
> become available

that's what release schedules are for. using a "time based release" pattern is 
just a way to create constraints on this in advance that have no real bearing 
on the needs of the software, but cause those writing the software to find 
some discipline to meet timelines. note what happens in closed source shops 
that deal with such artificial deadlines. it usually isn't pretty, and we 
don't have the same constraints (namely $)

> You can get those things by using when-it's-ready releases too, but I
> don't think it's as easy.

why not?

> I also wonder if they're not just two sides of 
> the same coin - when-it's-ready really means "when the core/most
> important parts are ready", and the rest are supposed to keep up.

yes, time based is just another way of saying "release schedule" except you 
are defining every release schedule from here on out, regardless of sanity.

> For lots of discrete components I don't see how that'd be possible.

the maintainers come together and say, "we need N months to accomplish this or 
that, which is our goal"... then you align all those needs/requirements and 
the release scheduler(s) set a time. KDE is no different in this regard, as 
there are several different types of components (libs, apps, etc). when 
disparity grows in a patterned way, the software can be released in stages. 
this is no different whether you have a set time span or not.

> useful, it has to include popular and widely used libraries: obviously
> both GTK and Qt fall into that category. The question then becomes, is
> it possible to get them synchronised enough that they can be a part of
> the same base?

it's irrelevant because these two toolkits are just two of the toolkits among 
many. they are TOO HIGH in the software stack to be broadly useful. or should 
we also include wxWidget, Java, XUL, OOo components, Motif, Mono, ......

> If the answer is not then perhaps the answer is to just not include
> widget toolkits in such a base at all. That would be a bit lame though,
> as if you start making too many exceptions like that the whole exercise
> loses its point.

hrm. ok.. let me rephrase the question to you: what do disparate desktops 
need? think about the question, and you'll discover the answer does not 
include "common widget toolkits". it does include hardware abstraction, IPC, 
windowing system(s), graphics libraries, etc.

please look at what has been going on at freedesktop.org to date and 
extrapolate from there.

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

iD8DBQFAUX+q1rcusafx20MRAsB9AJ9PXgFoDBMeXBmzelRtfVVaUuC9dQCfSbdW
3IE94I8IIV006YKiwZTlIb0=
=MIXX
-----END PGP SIGNATURE-----