On Fri, 2006-04-28 at 12:20 +0200, Patrice Dumas wrote: > I don't think this constraint is productive. As Axel said keeping > spec files synced is simpler most of the time for the packager. And > for > the users it depends, some want updates other don't. I would prefer > something along > > Maintainers are urged to consider that many users expect that only > severe bugfix or security fixes are fixed in maintainance state. > However > packagers may still update their packages if they find it more > convenient > or if they perceive that enough users want an update. > > This is fuzzy, but I think it is better that way. Because this leaves things fuzzy for end users. Some packages are updated, so why aren't all? It leaves things very ambiguous. We need to give users a clear message that "This release is in maintenance mode. Consider it deprecated. Please update." > > 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. > > For me the only rule should be > > When creating branches for distributions that are in maintainance > state > the packager should understand that he is commiting to maintain > them. > > But it is the same for active distributions, and this commitment is > still > on a voluntary basis. Again, fuzzy message to end users. Why do some packages get released on these older releases, but not other packages? We need consistency. > > 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? > > > When the Fedora Project drops support for a Fedora Core release the > > corresponding Fedora Extras is also dropped -- read this as > > "End-of-life, no new updates,support for that EOL distro will be > removed > > from the Extras buildsys". > > Agreed. > > > 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? I consider that > FE is unsupported (as in the no waarranty clause of free software > licences) > being a project based on volunteering. > > 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 > Support is a reasonable expectation that bug reports will get looked at, security updates will be addressed, etc... -- Jesse Keating Release Engineer: Fedora
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
