From the Fedora-Wiki-Frontpage: The goal of Fedora? The rapid progress of free and open source software and content. [...] Rapid innovation. [...]
That what I like about Fedora -- you get new kernel versions, new releases from hplip, sane, gutenprint an lots of other stuff during lifetime of a distribution.
But I sometimes get the impression other parts of the distribution follow a different update strategy than for example the software I mentioned above -- the X-Server for example. The Xorg server 1.4 from X.org 7.3 (released about two month(¹) before the currently estimated Fedora 8 release) for example will afaics not make it into Fedora 8. Instead we are backporting lots of stuff to the current Xorg server 1.3.
I completely fail to understand why. At least I'm not aware of any good reasons why we didn't update rawhide some weeks ahead of the official X.org release -- that how we do it for Kernel, GNOME and lots of other stuff in rawhide as well.
But well, it happens more and more often these days that I think the Fedora project is getting worse and not better, as everybody had hoped during the merge. Way to many Committees (often the same people in them(²)) for example make even easy stuff hard to realize -- that slows progress and frustrates contributors. What is missing IMHO is a strong leadership (³) which is more involved with the distribution we create and shows the direction forward.
BTW, Rahul, the current WhyUpstream draft starts with: Fedora Project has a strong focus on not deviating from upstream as much as possible in all the different software it includes in the repository. I agree that that's how it should be, but for the X-Server (which is a major part of our Distribution) it's definitely not the case afaics.
(¹) -- two month are one third of one development cycle!
(²) -- we fail to build new leaders -- most of the active community contributors, package sponsers and FESCo members were in the same or similar positions one or two years ago as well. That IMHO tells us that we fail to build a community and have a to high entry burden
(³) -- Max sorry, I know that you are doing a lot of stuff and really good work that needed to be done. Don't take that as critique on your work
Abonnieren
Kommentare zum Post (Atom)
6 Kommentare:
The xorg-server 1.4 is very problematic in all distros, it isn't a problem only of fedora.
Remember that the principal goal is make a good and stable distribution of linux, not a race of velocity.
Greetings.
>The xorg-server 1.4 is very problematic in all >distros, [...]
Very problematic might be a good enough reason to not ship it. As I said "At least I'm not aware of any good reasons [...]"
But on the other working closer together with upstream could have avoided a "very problematic" release.
But on the other working closer together with upstream could have avoided a "very problematic" release.
Yes, I agree in this.
Thorsten,
why don't you simply ask ajax, krh and arlied about the reasons for staying with 1.3 for F8 ? I'm sure they will be happy to explain.
Thats a good chunk of upstream right here in the Fedora X team, btw...
> why don't you simply ask ajax, krh and arlied
> about the reasons for staying with 1.3 for F8
The question was raised by somebody else on fedora-devel already, where ajax and krh answered:
https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00495.html
https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00498.html
But I don't find the answerers much satisfying as they don't really explain *why* they didn't update weeks ago.
Because the one part of 1.4 that's most broken is input, and we didn't think we had enough time to land that and also fix all the bugs in it before F8. That's why the X server contains tons of backports for everything outside of input.
Maybe rebasing earlier would have solved this. But, maybe not. I've seen basically zero patches from the Fedora community for X issues, and at least speaking for Red Hat's X team, reworking input isn't really high on our list of priorities, so fixing that would have taken away time from everything else we're already doing. So I don't have any reason to think rebasing earlier would have helped.
Kommentar veröffentlichen