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
Attachment:
signature.asc
Description: This is a digitally signed message part