Looking ahead to the 7.8 katamari

Dave Airlie airlied at gmail.com
Fri Jun 8 06:59:27 PDT 2012

On Fri, Jun 8, 2012 at 2:35 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Thu, Jun 7, 2012 at 9:30 PM, Alan Coopersmith
> <alan.coopersmith at oracle.com> wrote:
>> As is traditional when we release a katamari, I have created a new wiki page
>> http://wiki.x.org/wiki/Releases/7.8 to hold the incomplete todo items carried
>> forward from the 7.7 page, and a few other things that have been discussed but
>> not previously put into the wiki.
>> Developers, please use your X input event generating powers to activate the wiki
>> edit icon and enter text changes to make the contents more or less realistic.
>> Also, I know I said last time I wouldn't be doing another one (and my predicted
>> unavailability in the latter half of last year was correct, leading to the
>> release not coming out until this year), but this time I really mean it - I've
>> accepted new responsibilities at work, leading to less time available for doing
>> X.Org tasks, and passing on the katamari release manager baton is next on my
>> list of ways to balance it out.
>> Since no one seems to have screamed loudly about our katamari release cycle
>> growing from 6 months to 12, and now nearly 18 months, it might be reasonable
>> to plan on 7.8 coming out with Xorg server 1.15 in the second half of 2013.
>> If that's the schedule we want, a release manager or release management team
>> should be in place by this time next year.   The workload can be spread out,
>> especially the load of releasing individual modules - the main thing we've had
>> a single person for is deciding when to call it done and what to pull in or
>> keep out.   That could also be handled via a team small enough to reach
>> consensus without endless bikeshedding debate.  I will be happy to advise and
>> pass on any knowledge/scripts I have to whomever is willing to take this on.
> Does anyone care about an official katamari anymore?  Most
> OSes/distros just cherry pick the parts they want anyway.  If no one
> uses them, maybe they are not worth doing anymore?  If there is
> someone that uses them, maybe they can step up to handle them,
> otherwise we can just stick to component releases?

I do like the idea of having a specified set of known building
together components
for historical reasons, if the main weight is releasing individual
components I'm wondering
do we need some way to streamline the process a bit.

I've been contemplating releasing all the "maintained" but
"maintainerless" drivers in one
big super update, so I don't have to sign and send 25 emails.


More information about the xorg-devel mailing list