Core + Exrtas 2

[Christopher Aillon]

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.