Rahul Sundaram wrote:
Fedora is most cases, is way ahead in versions and that strategy
won't work much. You could borrow a few fixes like Fedora Legacy used
to but that is a small number.
It would only work in the versions where the code cycle continued into
RHEL and would take some coordination even there, with the tradeoff
that no duplicate work would ever need to be done on the development
side and there would be no incompatible version jumps to cause trouble
on the user side.
RHEL mostly freezes on everything and backports fixes selectively with
few version bumps in between. Fedora stays more close to upstream and
rarely backports fixes. If a security issue affects the recent version
of any component in Fedora, you just cannot borrow a fix from RHEL in
most cases as a result.
Yes, you'd have to coordinate this once the RHEL cut happens. With the
result being something actually useful instead of just another throwaway
beta. Fedora could just branch their next version at that point to
satisfy people wanting fresh meat every day.
But, how many things have big security risks anyway? In most cases
the ones to worry about are just the kernel, network daemons, and suid
programs - mostly things with standardized interfaces so backing up a
version or two shouldn't break anything.
You aren't considering things like Firefox which often requires security
updates. You cannot just go back a few revisions and just hope to not
break anything. Doesn't work that way. You don't even have to be a
developer to be aware of that. Any sys admin would be aware of how
brittle things can be.
How is that a particular issue? Even RHEL jumped FF versions in an
update, so whatever they do should be acceptable in fedora which doesn't
seem to follow any particular policy regarding version stability.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
