Thorsten Leemhuis wrote:
[EOL stuff]
Having read the many useful and almost exclusively constructive opinions
in this thread, I personally don't think that there are massive
fundamental differences between what everyone thinks, though the devil
is in the detail.
Personally, I 100% agree with the modest proposals that Thorsten has put
forward to get the ball rolling.
A few random but important points that I have picked up from the thread
in general:
1. no completely new packages in EOL/legacy/maintenance (except by FESCO
overrule, as Thorsten proposed). I think that almost everyone is agreed
on this.
2. End-user expectations need to be set clearly. My own feeling is that
we should set end-user expectations to the lowest common denominator;
i.e. something like "legacy releases have no expectation of any updates
whatsoever. Notwithstanding that, a security respose team will, within
the contraints of a volunteer group, try to provide security updates to
packages in reasonable timescales, prioritising as they feel is
appropriate". Better to set this expectation and exceed it than set
something much higher and fail.
3. On the topic of backporting security fixes, I think this is a bit of
a red herring. Some have suggested NO new package versions, only
backported fixes. This doesn't really make a lot of sense: what if
upstream releases a new version that contains just the security fixes?
Or the security fixes plus tiny bugfixes too? This is pretty common and
artificially forcing someone to diff package version N and N+1, then
apply the patch to version N but call it version N release++ makes no
sense. Now, obviously this leaves it down to the maintainer: if we are
leaving it open that they can upgrade packages as they see fit for
"security" reasons, there's nothing stopping them upgrading to some big
new version. But then that's the case with FE in general: a lot of it is
down to trust in the maintainers not to do things that are completely
out-of-line with what the Project as a whole is trying to do.
Just a few thoughts anyway.
Tim
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
