[daniel at freedesktop.org: Timeline, and slippage]

[Owen Taylor]

On Fri, 2004-07-30 at 16:09, Carl Worth wrote:
> On Fri, 30 Jul 2004 15:25:48 -0400, Owen Taylor wrote:
> > So I don't see any duplication, much less massive duplication between
> > the specification and platform releases. They will be coordinated
> > as appropriate, they don't need to be the same.
> 
> I agree that the nature of the products and the release criteria are
> different for software and specifications. But I do see a lot of
> similarity between the release process. For example, the ways in which
> release managers interact with those doing the work is largely the same.
> 
> And there are other good reasons to share things as much as possible
> between these efforts. I don't anticipate a surfeit of release-manager
> time that it makes sense to have independent processes.

But will combining the processes really save people time? If the
processes are essentially separate and different, then having
two releases means you can have two release teams/managers, rather
than one doing twice as much work.

> Another aspect that might be important is to reduce confusion between
> what "products" it is that freedesktop.org is producing.
> 
> So that brings up issues such as naming, versioning, and release
> timing. The interaction between software and specification leads to
> interesting questions. Should software supporting a specification always
> be released simultaneously? Should the two products be released at the
> same frequency but with a phase difference?

Right now, few of the specifications under discussion are actually
implemented by software that is part of the freedesktop.org platform
release. Which makes the issue somewhat less critical.

There's inherently achicken-and-egg in the software/specification
process:

 - Released software really shouldn't be using stuff that isn't
   yet standardized
 - But specifications shouldn't be standardized before the 
   existence of interoperating implementations.

This isn't a freedesktop.org specific problem. Note the deployment
of internet drafts that were later rejected. But the rapid release
cycles of open source software make the problem worse. The time
between implementation of a draft and the next release of the software
is small.

The ideal cycle is:

 - Draft proposal
 - Prototype implementations
 - Specification version release
 - Software release

So that implies that same frequency with a phase difference 
of a few months may be the right model.

> I think it is important that the answers to these issues be decided
> jointly for the software and specification efforts.
> 
> Maybe all I'm saying is, "Yes, these efforts need to be coordinated as
> appropriate. Let's decide now what that means."

I certainly didn't mean to cavalierly dismiss the issue. I'm just 
not sure we can sort out the interaction issues until we see the
processes run on their own.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040805/48467fcb/attachment.sig>
-------------- next part --------------
_______________________________________________
xdg mailing list
xdg at freedesktop.org
http://freedesktop.org/mailman/listinfo/xdg