Bill Nottingham schrieb:
> Thorsten Leemhuis (fedora@xxxxxxxxxxxxx) 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
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________
fedora-advisory-board-readonly mailing list
fedora-advisory-board-readonly@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
