Long-term package versions (RHEL 5+ extended to 10 years until EOL)

[Bill McGonigle]

On 02/01/2012 11:52 AM, Adam Miller wrote:
> just that we continue along with
> challenges we face today

'Just' is always tricky in these situations.

I've been chatting with the Bugzilla packager on Bugzilla ('sup dog)
about this, and I think it's worth talking about policy.

EPEL6 currently ships Bugzilla 3.4, a branch that's about to become
abandoned upstream.  Xavier has been doing backports of security fixes
to 3.2 (EPEL5) and could conceivably do this for 3.4 for a while, but
doing this for the next 8 years is a tall order.

The problem with the backports approach is that backporting difficulty
doesn't scale linearly.  Backporting a patch at year 1 is probably
pretty easy - at year 10 it could be a major project.

I think it's possible that the current EPEL policy may have been
flirting with the edge of what is possible with volunteers and adding a
significant time extension to that could push it over.  Redhat has
decided that it will pay its employees to make this happen for their
[smaller] set of packages.  I don't think it necessarily follows that
this is the right decision for EPEL.

In the case of Bugzilla, EPEL policy, as I understand it, precludes the
rebasing of 3.4 to 3.6, 4.0, or 4.2 branches because upgrade
compatibility isn't trivially guaranteed.  The standard case would be
satisfied by running the checksetup.pl script on upgrade, but certain
extensions and customizations might cause that to fail.

Xavier has entertained the idea of having a bugzilla36, bugzilla40, or
bugzilla42 package for those seeking features, but that raises questions
of usability 'yum install bugzilla??' and perhaps eventual abandonment
of the 3.4 'bugzilla' package.

Where we have mainline Fedora packagers who spend a bit of time on EPEL,
major backporting may not be at all interesting, and even if it is,
that's time that can't be spent on other Fedora work.

Some options I can think of that might help:

1) deviate from Redhat policies (EOL date, etc.)
2) allow the packager to decide it's time to rebase (with guidelines,
maybe a yum plugin)
3) drop unmaintainable packages when that time comes (perhaps a CVE + n
days policy)

But that's just off the top of my head - others probably have better
ideas.  I just think it's important to not trivially accept 'eh, three
more years' as policy without fully considering the costs - no doubt
Redhat made a serious accounting of their costs before arriving at their
decision.

-Bill
-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill at bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle