Fedora too cutting edge?

Hans de Goede j.w.r.degoede at hhs.nl
Wed Jan 9 19:45:23 UTC 2008


Yaakov Nemoy wrote:
> On Jan 9, 2008 1:45 PM, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>> Does this mean that Fedora should not have shipped the new stack? No it
>> doesn't! Getting code out there early into many hands for testing is a good thing.
>>
>> What IMHO we should have done is build both the new and the oldstack, which is
>> possible on the kernel side, and modify our patches to userspace to support the
>> juju stack, so that the userspace libs can work with either one. On top of this
>> we should then have written a small gui utility for easy switching.
> 
> Supporting two versions of anything, especially on the same system is
> much harder than it looks.  The people in charge have to make sure
> that the old version still works, even if it's unmaintained upstream,
> the new version works somewhat, so it doesn't completely suck, the
> userspace stack surrounding kernel bits has to work equally as well,
> so that the transition is smooth, the interoperability between the
> new/old components and the rest of the system is equal, etc...
> 
> Then they have to worry about security advisories on both components,
> managing two packages where there could be one, propagating static
> materials twice, like documentation and configuration details, writing
> documentation on how to switch back and forth for those butterflies
> that are interested in making things work well, etc...
> 
> All in all, it takes alot more manpower than what's available right now.
> 

You are talkin in generivs, where as this are 2 very specific cases, in both 
cases I gave the alternative is still actively maintained upstream. In the case 
of firewire, the alternative is even the preferred choice of upstream, in the 
case of pulseaudio, pa lies on top of alsa, the alternative, so surely we must 
still maintain that! I'll admit that in the firewire case there would be some 
extra work, but not a lot.

Regards,

Hans




More information about the fedora-devel-list mailing list