Jeff Spaleta wrote:
> I'm not going to attempt to speak for anyone else as to whether an
> extended maintenence period is necessary or even desirable. I do not
> desire it, and if the period would extended I would not be able to
> maintain the packages for that extended period of time and would
> require additional co-maintainers who would do that, while I
> concentrated testing for the newer releases.
Almost all the proposals focused on security updates. Is it really that hard
to provide security fixes only (and no other fixes) for the 13+ month old
releases (and "business as usual" for the 12- month old ones)? This is a
serious question, not a rhetorical one. I think it depends on the packages,
really: For KDE, the work would be near nil as there are very few security
issues in KDE (especially in proportion to the size of the packages) and
for those, KDE upstream publishes backported fixes even for pretty old
releases. And there are plenty of small packages in Fedora which may never
see a real security issue in their entire life. On the other hand, core,
security-critical packages like the kernel, servers, web browsers, image
processing libraries etc. are the real sources of trouble and those the
defunct Fedora Legacy project struggled with the most. (For example
xine-lib is a royal PITA security-wise.)
By the way, if you think security fixes only would be a crappy form
of "support", consider that it's all Debian is ever offering for their
stable releases. So I don't think dropping back to that model after 13
months of full upgrade support would be a bad thing if we could pull it
off. But the problem is that the amount of work is hard to quantify and
that we can't really experiment with it without the infrastructure to do
so, which is near impossible to set up outside of Fedora (it took years to
get RPM Fusion set up - sure, there are plenty of small repositories with
lower-tech infrastructure, such as my CalcForge repository, but there's no
way that infrastructure can be used for a project like this, it starts from
bandwidth (there's no way the VPS which hosts repo.calcforge.org can serve
OO.o security updates, we'd exceed our bandwidth quota in a jiffy), but it
also touches things like an SCM (I don't even have an SCM set up for the
CalcForge specfiles) and a build system (having a single person run mock by
hand to do all the builds as I do for the CalcForge repository isn't going
to scale at all)) and which Fedora is not ready to provide.
FWIW, I personally have near nil interest in old releases (I think running
old software is not what Fedora is for), but I would be willing to take
care of security fixes in the old releases for the packages I maintain or
comaintain because for those packages, except for xine-lib (which can be
dealt with by just syncing the version upgrades from the newer releases
when they fix security issues, they don't break API/ABI except for plugins,
which are all in the single xine-lib-extras-freeworld package), it's a
negligible amount of work compared to the version updates and bugfixes we
regularly do in the non-EOL releases.
Kevin Kofler
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
