Ralf Corsepius wrote:
On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote:
Ralf Corsepius wrote:
On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote:
Ralf Corsepius wrote:
On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
No, he's asking about introducing new packages to a released product.
Say
Fedora 7 goes out the door with a given package set. Three weeks later a
great new package gets added to the Fedora universe, what kind of policy
would there be in making this package available to the Fedora 7 users?
IMO, basically like FE has been doing it, so far, except that breaking
APIs, ABIs and packages deps etc. must not happen.
That language may be a bit too strong, as I can think of cases where an
essential update may end up breaking ABI, though it's not unreasonable to
to make policy such that it *should* (not must) be avoided.
Well, this "must" is the core point about all this - Fedora should be a
stable distro.
I guess we disagree then.
<bitter sarcasm>
Welcome to the wonderful "world of rawhide" - Good Night, Fedora!
You once had been a usable distro, but your masters now seem to be
wanting to convert you into a jungle :(
</bitter sarcasm>
I consider ABI compatibility as just one part
of what defines a stable distro, but, imo, there are certainly cases
where breaking ABI is justified (for essential features, bug fixes, and
yes, stability sometimes).
Please ask RH how they have been handling Core, so far.
I don't know how many times I've been told: "No API-changes, no ABI
upgrade, no feature upgrades, often not even bugfixes (aka
FIXEDRAWHIDE)"!
There is no one-size-fits-all solution here. Sometimes, it is just
plain dumb to not break API.
Case study: https://bugzilla.mozilla.org/show_bug.cgi?id=296639 fixes a
few critical security issues and other important bugs by differentiating
priveleged and unpriveleged window objects. Effectively, this is a
complete re-architecturing of the way DOM windows are handled internally
to gecko, required because the previous architecture was flawed by
design. It's a very large patch, which caused quite a number of
regressions. Still, it was deemed necessary to get this fix into Red
Hat Enterprise Linux 2.1, 3, and 4 for security purposes in a meeting
with our security response team, product management, QA, and myself.
Option A: wait for someone else to do something. wait time is high.
potential for regression is high.
Option B: spend many weeks on a solution, getting little exposure on it
before releasing it to the wild as an update. Potential for regression
is high.
Option C: take the new version wholesale. The flaws are guaranteed
fixed. API will break slightly, but with warning and possibly a little
help, people can adapt. Most applications were fine with little to no
changes. Eclipse needed some help, but I helped the team get around
that. Devhelp needed a little bit of help, but it didn't take long.
Naturally, we went with option C, after discussing the options, although
it became clear quickly that option C was the best choice. I see no
reason Fedora can't make informed, intelligent decisions if the need
arises. Expressly forbidding these decisions to be made is the wrong
thing to do.
Rex is correct. We should look to avoid these situations if at all
possible. But sometimes, there is no good alternative.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
