Doug Ledford wrote:
and in those days Fedora Core did in fact have the more conservative
update style as a general rule.
Oh really?
http://lists.fedoraproject.org/pipermail/announce/2005-December/thread.ht...
| Fedora Core 4 Update: arts-1.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdelibs-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdebase-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeaccessibility-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeaddons-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeadmin-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeartwork-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdebindings-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeedu-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdegames-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdegraphics-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdemultimedia-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdenetwork-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdepim-3.5.0-0.2.fc4 Than Ngo
| Fedora Core 4 Update: kdesdk-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdeutils-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdevelop-3.3.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kdewebdev-3.5.0-0.1.fc4 Than Ngo
| Fedora Core 4 Update: kde-i18n-3.5.0-0.1.fc4 Than Ngo
That's KDE 3.5.0 for Fedora Core 4, which shipped with KDE 3.4.0. It got
subsequently updated to 3.4.1:
http://lists.fedoraproject.org/pipermail/announce/2005-June/thread.html#950
3.4.2:
http://lists.fedoraproject.org/pipermail/announce/2005-July/thread.html#1164
3.5.0 (a feature release!):
http://lists.fedoraproject.org/pipermail/announce/2005-December/thread.ht...
3.5.1:
http://lists.fedoraproject.org/pipermail/announce/2006-February/thread.ht...
3.5.2:
http://lists.fedoraproject.org/pipermail/announce/2006-April/thread.html#...
and finally 3.5.3:
http://lists.fedoraproject.org/pipermail/package-announce/2006-June/threa...
at which point Fedora Core 4 reached its end of life.
How's that different from what we're doing now?
I think a rolling rawhide could be done, but it would require more
work
than it takes today, and in so doing we could satisfy both user groups.
I'm willing to do my part and commit to that work (which is all that's
really required to solve your claims that people will leave things in
rawhide-unstable and they will diverge...if people commit to taking care
of *finishing* projects they start in rawhide-unstable, it will not
diverge over time but will instead remain very close to rawhide).
The problem is that you want to conduct your experiments at the expense of
our existing userbase. Those users (including me) are less than thrilled
about being the guinea pigs for your experiments which even you aren't sure
will work out.
You think any sort of rolling-rawhide is a lost cause, and you
personally couldn't care less about the group that wants a more
stable/conservative update stream in released products, so you would
rather save the extra work that *any* solution would entail and tell the
other group of people "So long, don't let the door hit you on the way
out". To that end, you will use what amounts to fatalism as a basis for
objecting to the technical merits of any proposed solution (aka, it's
not that what I proposed can't work, just that you think it won't
because you and people like you won't participate and it will therefore
fail).
You call it fatalism, I call it realism.
Kevin Kofler