X server 1.10 development cycle

[Daniel Stone]

Hi,

On Fri, Sep 10, 2010 at 11:41:15AM -0700, Keith Packard wrote:
> Looks like the 1.9 server release has gone off fairly well, and I think
> the few changes we made in the process helped quite a bit, in
> particular, having a release tracking bug made it easy to find things
> that people wanted fixed, and several of them actually did get fixed,
> including some ancient ones (like bug 3040).

Yeah, I've been surprised how smooth it seems to have been this time
around.

> I'm also still interested to hear how we can de-modularize the system to
> some extent where it would be useful. Merging the protocol headers into
> a single package would be a good step, but it would require someone to
> step up and offer to take charge of doing release management for the
> whole thing.

I'm happy to do it - it's definitely worth it to get a more bisectable
server.  The main problem I can see is versioning when you have one or
more extensions under reasonably active development; rather than
bumping the package version and releasing the entire tree every time you
change API, we could export a standard major.minor[.rev[.subrev]]
version for each extension.

major and minor would correspond to the major/minor wire version, with
rev < 99 for new constants, clarifications to the text, etc.

However, rev >= 99 would let you add new API and then change or remove
it, so you'd depend on the strict subversion (e.g. 1.4.99.3).  Even if
you're actively breaking something, I'm happy to take rev >= 99 changes
in xproto-next and keep rebasing them, as long as it doesn't break
anything relative to master.

So, with all that in mind, this is what I'd suggest in terms of schedule
for 7.0.18, with an API freeze when the merge window closes:

                                xproto          xserver
Merge window closes:            2010-11-1       2010-12-1
Non-critical bug deadline:      2011-01-1       2011-02-1
Final release:                  2011-01-18      2011-02-18

It's fairly tight, but a bisectable server for three and a half months
before release should make people happy.

Any thoughts?

> I think Peter Hutterer is almost convinced that bringing the input
> drivers into the server would help let us fix the API/ABI issues in that
> interface faster.

Sure.  I'll be maintaining an input-next branch for multitouch and
xkbcommon anyway, so I'm also happy to track Peter's xfree86 API changes
there if it'd help.  Neither multitouch nor xkbcommon really change the
xfree86 API, so it should be fairly smooth.

> I asked about changing the length of the release cycle last time and it
> seemed to me that the general consensus was that we should leave it at 6
> months, at least for now. I'm OK with that; we don't have so many
> changes coming into the server than a 3 month cycle seems required. If
> we start integrating video drivers into the server, we may want to
> reconsider to make sure we can get support for new hardware out in a
> timely fashion.

Or a more gradual change, say four or five months to start with.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100920/8cf6febe/attachment.pgp>