Will The X.Org 7.5 Release Schedule Be Met?

[bridgman]

Yeah, the big issue is that the ratio of developers to code size, or complexity, or whatever metric you want, is *much* lower for xorg/dri/mesa than for the kernel. It doesn't help that a lot of the high impact work being done is in the mesa and drm trees, which aren't strictly part of xorg but which consume developer resources and impact the xorg schedule.

The biggest problem still remains the mismatch between user expectations and the number of people rolling up their sleeves (assuming they have sleeves) and helping the work to get done.

[TechMage89]

Just a comment on the lack of developers from the perspective of one who is interested:

I feel like the lack of documentation of the Xserver is a major barrier to entry for new developers. What documentation there is is fragmentary, scattered over dozens of different places, and frequently out of date. "Use the source, Luke" might be reasonable for a small project, but for something with the size and complexity of the Xserver, it makes things hard on new developers.

If there were a book on the architecture and internals of the Xserver, I would buy it. It happens that there is only one that is something like 15 years old and corresponds to little that exists today. As it is, even after over a year of poking around, I still can't even find a clear description of the X protocol!

If you want more developers, please spend some time making comprehensive documentation of the Xserver! I know it's tedious and has no direct impact on progress, but I believe it is the best way to attract new developers!

[Ryzzen]

I don't like these articles, and wish Michael/Phoronix would stop the bashing.

If you don't like the X.org schedule, write an article titled "Number of X.org core developers still small" or something.

I don't think bashing the current dev's is gonna help get anything done faster, and is just going to make those currently volunteering their time feel less appreciated for their efforts.

So, on that note, let me say - Considering the resources, I think the current X.org devs are doing a fine job adding features and moving things forward, and I for one appreciate their efforts, and will be happy to use those features When It's Done.

I completely agree. Harping on them for being late accomplishes nothing. Why is it such a crime to be late, anyway? Perhaps they should just change all of their future release dates to "When it's ready" to avoid the Phorobashings. That is, if they cared, which they probably don't.

...perhaps we need a publicity campaign. "X.org: Your patches are even more welcome than they were before."

You are indeed most awesome, dude.

[deanjo]

perhaps we need a publicity campaign. "X.org: Your patches are even more welcome than they were before."

~ C.

Just make sure that it has a nice disclaimer in the title.

X.org: Your patches are even more welcome than they were before.

* Unless you work for nvidia and reject a fallback patch on pure political reasons alone, remember "This is not a democracy, votes will be ignored'

[seba]

they should just forget the release schedule and simply just put WID (when it's done)

[val-gaav]

Two things.
and the only real problems are making sure that fglrx and nvidia don't get broken too badly while still trying to fix the God-forsaken code that history has left us with.

It's interesting and somewhat surprising that xorg devs care about fglrx and nvidia ... In fact I'm very surprised.

[krazy]

* Unless you work for nvidia and reject a fallback patch on pure political reasons alone, remember "This is not a democracy, votes will be ignored'

So you want already stretched developer resources to maintain a wrapper or stable api for the benefit of a single closed-source driver vendor to make sure that its driver continues to work as the ABI changes?

I can't think of a less productive use of precious development time.

[deanjo]

So you want already stretched developer resources to maintain a wrapper or stable api for the benefit of a single closed-source driver vendor to make sure that its driver continues to work as the ABI changes?

I can't think of a less productive use of precious development time.

lol, sorry but that patch required about as much maintenance as a stuffed animal.

[R3MF]

The reason they went back to a 9-10 month release is because they wanted a longer period of testing, tweaking, and refining of the base system. I am glad they went back to this model that was successful for them in the past. They jammed the last release in 6 months that did not allow them sufficient time for bug fixes resulting in many normally classified Major bugs to be downgraded or put off to a future release.

i accept your point, but i care more about the validity of my original, to whit: "with opensuse's 9-10 month release cycle they would be daft to lumber themselves with a 2008 X.org release for a distribution whose life-cycle mainly covers the year 2010. especially for the sake of a few weeks."

[Kjella]

i accept your point, but i care more about the validity of my original, to whit: "with opensuse's 9-10 month release cycle they would be daft to lumber themselves with a 2008 X.org release for a distribution whose life-cycle mainly covers the year 2010. especially for the sake of a few weeks."

Waiting for all the planets to align inevitably leads to Debian style releases - few, far between and invariably late. As much as I can bash Ubuntu for all the shit they break by shipping every six months no matter what state it's in, I've found it better than the alternative...