why I'm using Ubuntu instead of Fedora ATM

[Thorsten Leemhuis]

Bill Nottingham schrieb:
> Thorsten Leemhuis (fedora at leemhuis.info) said: 
>>> * support: whether or not it is reasonable/sustainable, Ubuntu's
>>> support policies for their non-LTS distros are more generous and more
>>> sane (i.e., all backports, no new features[1]) than Fedora's, which is
>>> a factor for someone like me who doesn't have much time to screw
>>> around with installations, re-installations, new releases that
>>> introduce new bugs, etc.
>> Agreed. We always point people to RHEL or CentOS and I think that 
>> becomes more and more a problem, especially now that Legacy is dead.
>> A Fedora LTS (two years? maybe the server parts ever three?) now and 
>> then (every second or third release?) from a new Fedora Legacy (needs a 
>> different name) would IMHO a nice solution.
> I think you missed the point of what he said. He was talking about
> how the *normal* release was handled - nothing about long-term support.

Seems so.

/me slashes thl

/me makes mental note: don#t write mails in a hurry, looks bad

> As for any sort of long-term Fedora support, what we need to see is
> some sort of market for it - we had the inital Legacy, and, realistically,
> NO ONE WANTED IT ENOUGH to actually work on it.

Maybe it died because it/we tried to much? I think we should be able to
get enough people together to support only one distro for a longer time
at a certain period, e.g.:

FC6 -> supported until FC8 get's out + one month = 13 months basic
support. Support FC6 after that by a new Fedora Legacy for for another
18 months = 31 Month or round about two and a half years in total. FC11
would be out by then and we could start maintaining FC9 for another 18
months (it would be otherwise EOL by then)...

> [...]
> Moreover, considering he's talking about 'all backports - no new features';
> Extras is *significantly* worse than the current Core in this regard.

Fully agreed, but Extras started as a rolling release scheme and never
stopped and nobody yelled loudly to stop that. That will change with F7.
>>> * community growth: this wasn't a factor for me, but Ubuntu has very
>>> aggressively and very publicly pursued non-engineering community
>>> involvement. Make people feel wanted and love, and they'll want to use
>>> your distro.
>> Strongly agreed. I more and more think we need a "Fedora Experimental 
>> Kitchen" project where stuff that's not yet covered by the Fedora 
>> Project can be developed while the users feel as being a part of the 
>> Fedora project -> this would help getting people involved and grow up.
>>
>> Kmods, alternate kernels, Firefox2 for FC6, Respins, Live-CDs, new 
>> Distributions Spins (Fedora Audio, Fedora BrandNewIdea anyone?) could be 
>> suitable to be done under the hood of the "Fedora Experimental Kitchen".
> OK, you've lost me. How is adding an experimental repo for highly
> technical things (kmods, alternate kernels, etc) about embracing
> the non-engineering community?

It was an idea that came to my mind when the recent kmod kernel thing
came up and I thought I could boot my feed out a bit into the cold water
with outlining them it a bit and to see what comes out of it.

>> I'm wondering if we could provide solutions for both users: One update 
>> channel that only gets security updates and important bugfixes while the 
>> other is a bit more bold -- we for example could have firefox2 in the 
>> bold channel for FC6 while shipping the latest firefox 1.5.x in the more 
>> conservative channel.
> So, an idea like this:
> - starts to exponentially expand the QA problem

The stable update channel could remain the official repo with a slightly
more conservative approach then now.

> - breaks dependencies across repositories (we have no xulrunner)

The maintainers of the more bold channel would need to fix this, too.

> - fractures the community into different splinters

People want different things:
group1: some want always the newest and greatest -> rawhide
group2: some want a slightly more stable approach, but also quite new

         stuff (Exrtas rolling release) -> bold repo
group3: some want only security fixes and important bugfixes
         (traditional approach)

I'd like to have group2 on board, even if there is a small split.
*Maybe* we would not need it if the devel tree was a bit more stable.

CU
thl