> > * During its legacy maintenance state, do we lock a branch, so that no
> > new packages (i.e. packages which have not been in Fedora Extras before)
> > may be added? With adding new packages to a legacy branch comes the
> > promise to maintain those packages in that branch till end-of-life. Else
+1, lets stop (or strongly discourage) new work in eol-ed versions
> I think that it would be right to let packagers who want to to add new
> packages, a packager that wants to add a version for eol fedora
> versions shouldn't be discouraged to do so. But I also agree that it
> should be accompanied by the promise to maintain the package for that
> branch also, at least until he orphans the same package for all the fedora
> versions that are not eol.
>
> In the same way I think that packagers shouldn't be discouraged to
> update to the newest releases, and not only backport security fixes, if
> the packager prefers that. And it doesn't cause too much deps issues, of
> course.
-1, I strongly disagree based upon end-user expectations
I vote for consistency. That is, all packages within both FE and FC are
eol-ed more-or-less simultaneously and are treated in a very similar
manner. The overall trend here seems to be a convergence (or a blurring
of the distinctions between) of FE and FC. Having different eol policy
and/or practice within FE/FC (or different expectations on a per-package
basis as Patrice suggests) is, IMO, a lot of confusion for very little
gain.
Expectations regarding bug/security fixes, updates, and other changes
should (in an ideal world) to be communicated loudly, clearly, simply,
and *consistently* to all end users. Muddying the waters with different
per-package or per-repo or per-whatever behavior is not helpful.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3@xxxxxxx ed@xxxxxxx
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
