Am Freitag, den 28.04.2006, 12:20 +0200 schrieb Patrice Dumas: > > === EOL. > > > > state. In this state maintainers will be allowed to issue updates to > > existing packages, but Maintainers are strongly urged to only issue > > severe bugfix or security fixes. New software versions should be avoided > > except when necessary for resolving issues with the the current version. > > I don't think this constraint is productive. As Axel said keeping > spec files synced is simpler most of the time for the packager. The user IMHO is more important than the packager. > And for > the users it depends, some want updates other don't.[...] Doing both (e.g. 50% of the packagers update their packages to new versions, the other 50% only fix bugs) is IMHO the worst we can do. If people want new stuff they are probably installing new distribution versions in any case (not all, but most). That's why I prefer "normally no big updates" variant for those that prefer a stable distributions. > > Branches for new packages in CVS are not created for Distributions > > that are in Maintenance state. FESCo can approve exceptions of this rule > > if there are good reasons for it. The official package maintainers are > I completly disagree with that. If a user don't want new packages that > entered extras while in maintainance state he shouldn't install new > packages. In my opinion the maintainer could be able to add new packages > for distributions in maintainance state, if he is confident that he > will maintain it. [...] I can live with that if others agree with it. But there were some people in FESCo that don't like this idea. > > urged to fix their packages also for Distributions that are in > > Maintenance state. They should work hand in hand with the "Security > > Response Team" in case they don't have access to older > > distros anymore to test their updates. > What about co-maintainership, if a maintainer volunteers for maintaining > the old branches? I left co-maintainership (and your proposal) out for now because it would have complicated things even more. But we should work on the details for "co-maintainership" soon. >[...] > > The EOL Policy depends on the creation and a working Security Response > > Team and especially the part of it that "will lend assistance as needed" > > if the maintainer is unable to fix the package -- if that group does not > > start working properly until June 15 2006 we'll send out a EOL for > > Fedora Extras 3 -- means: "Packagers can still update things in cvs and > > build updates for now, but the official state of Fedora Extras 3 is > > 'unsupported and End of Life'". In that case we'll try to improve for > > FE4 and later. > > What is the meaning of 'supported' for FE4 and FE5? Good question. > I consider that > FE is unsupported (as in the no waarranty clause of free software licences) > being a project based on volunteering. Maybe -- but that's not a reason to leave known security bugs unfixed ;-) > Anyway, beside all that I said above I think that, as long as the > infrastructure and the guideline are kept unchanged, I am all for saying > > "Packagers can still update things in cvs and > build updates for now, but the official state of Fedora Extras 3 is > 'unsupported and End of Life'" > > regardless whether there is a security team which will be nice and helpfull, > but even more for current versions than for eol/in maintainance versions. I tend to "lets give the Security Response Team some (two? three?) months and revisit the EOL plans then again" ATM CU thl -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
