[Xcb] Thinking towards 7.6 katamari, including xcb

[Peter Hutterer]

On Mon, Oct 26, 2009 at 01:28:40PM -0700, Keith Packard wrote:
> Excerpts from Peter Hutterer's message of Thu Oct 22 23:15:36 -0700 2009:
> 
> > How many of these requests were driven by our permanently late release
> > cycle? i.e. would an actual 6 month release cycle classify as "shorter
> > release interval"?
> 
> Well, 1.6 was released 6 months after 1.5, and 1.8 will be released 6
> months after 1.7, so we're actually not doing too badly on average
> here.

1.4.1 was planned for November, released in June.
1.5 was planned for March, released September.
1.7 was planned for July, released October.

If you ask around which release dates ppl remember, my bet is on those that
were late, not those that were on time. In the same way as one only
remembers the trains being late, but never the ones on time. 1.8 is still in
the future, so it's risky to use that as a reference point.

> > Is there enough churn in the server to warrant more frequent releases?
> > The larger changes are mostly complete now and looking at my schedule I
> > doubt XI2.1 will land for 1.8.
> 
> Once we merge the drivers back into the server, the level of change in
> the overall package will go up dramatically. Yes, I'm hoping that the
> feature set in the core server will stabilize, but we've got a pile of
> API/ABI changes to work through that we can only realistically do with
> integrated drivers.
> 
> > If there aren't enough features, having extra releases and the associated
> > branches increases the time spent release-managering. looking at how close
> > 1.7 is to master I wonder if we'd end up with multiple branches that are the
> > same except for a few patch sets.
> 
> My hope is that our need for backporting changes will be reduced by
> shrinking the release window. We had several 1.6.x releases mostly
> because 1.7 was a delayed -- there were features pending on master
> that OSVs needed to ship before 1.7 did. I back-ported more than just
> bug-fixes here, which I wasn't entirely happy about.

My worry is less about active backporting but about missing out on
cherry-picks. If the branches are close together, 1.8, 1.9 and 1.10 may
needd patches [A-Z], but 1.9 forgot to cherry-pick [K-M] and 1.8 didn't
cherry-pick E, M, N and O. So although they're close enough, you're suddenly
running different combinations of patches and bugs.

I don't know of a tool that helps with this.
 
> > How long do you want to maintain stable branches? Or do we just keep
> > maintaining _some_ stable branches and let the others rot? If so, which
> > ones?
> 
> I'd be willing to ship two versions and back-port patches from master
> to both of those (so, 1.7.x and 1.8.x while 1.9 is in
> development). That's more than we've done in the past, and provides a
> 6-9 month window given 3 month release cycles.

Who's going to nominate the patches for backporting though? Nominating a
patch means the developer has to know that the other branch has the same
issue and test this locally. That requires a lot of time, expecting this for
3 branches only really works if those haven't changed much between releases.
Which I guess will be the case with 3-monthly releases, but that's a bit of
a loop there then.
 
> > Deployment is -largely- distro driven. with our past track record regarding
> > QA I'm not sure how many distros are willing to deploy a new server update
> > during their stable cycle. At which point you end with server releases being
> > skipped by distros altogether.
> 
> I doubt we'd manage to skip all of the distros, and in any case,
> re-integrating the drivers into the server should help bring back
> people willing to try a new X server/driver combo.

Provided our pre-commit QA goes up. I've been running git master since the
MPX merge and my biggest worry was always having to update the video driver.
I usually lost a day to get things running again. I'm sure others had
similar issues with input, except that I knew how to fix those on my box so
I wasn't worried about them.
If I have to drag down the whole lot each time, I'd be seriously worried
about running git again.

> > tbh, I'm not convinced yet of the benefits of shorter release cycles
> > (shorter than 6 months, that is).
> 
> I can't support a 6 month cycle in my video driver, and I doubt other
> video drivers could either; hardware changes too fast. If the video
> drivers are to be re-integrated into the server, we'll need some
> compromise in how often the X server is released.

How many of these hardware changes require a new server?

The dependency here seems to be
- we pull the drivers into the server
- drivers need faster updates
- the server now needs more frequent releases

If the drivers aren't pulled in, then the server can trot along slower.
So the real question is - does the benefit of pulling the drivers into the
server outweigh the costs of releasing and maintaining multiple server
branches?
The decision to merge seems to have been made already, so I guess that
question is answered.

Cheers,
  Peter