Re: Thoughts and a possible plan

Well, I'd like to start by saying it seems we do agree on one thing -
that such a shared platform would be useful to have! 

I'll use the term "base" from now on to better reflect what it really is
- the term platform normally conjures up images of large and consistent
APIs developed and managed centrally which isn't really what I was
proposing. I can see that was a mistake.

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

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.

So they key points of disagreement seem to be:

* Time based or not
* Toolkit issues
* Licensing
* Portability

The last two are just policy related. If/when such a desktop base is
developed, debates would be had and whoever the maintainer was would
have to make a decision. I don't have strong feelings either way, and as
the "base" is entirely hypothetical right now it wouldn't matter if I
did.

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?

There has be be some compelling advantages to using a particular set of
libraries, in other words. The advantages of a time-based base release
are:

* You know the software you're depending on is up to date and modern
* You have some degree of predictability as to when a new platform will
become available

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

I just foresee a world of pain in trying to draw the line when using
something as arbitrary as readyness. That works for projects like KDE
because it's all held in one place, compiles together, is used
internally by everything else etc so you can check it out of CVS, build
it, and get a good feel for how ready it is. For lots of discrete
components I don't see how that'd be possible.

Finally, toolkit issues - again the "hotlist" I proposed was just to get
some discussion going. You've got to start somewhere. For a base to be
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? 

I don't see any fundamental reason why not, though I can see one big
issue might be that TrollTech consider commercial-driven
deadlines/priorities more important than ensuring they release on
multiples of N months. I guess we'd have to ask them.

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.

thanks -mike