Backporting policy

[Axel Thimm]

Hi,

I just realized that all nice legacy talks about rpm upgrades,
infrastructure, repository mixing etc. have missed some very important
_content related_ points, especially the workflow/policies for
patching/backporting.

It is quite clear to me that the profile of this group is intended to
create backported fixes. An important link has already been posted
here by Russ P. Herrold:

     http://www.redhat.com/advice/speaks_backport.html

Now you can either

o do it the hard way: When a security related or other problem pops
  up, identify the problem, and patch the version coming with the
  distro. This ensures that the APIs/ABIs remain in place, and that
  the QA still applies, if the fix is indeed small enough and the
  patched software QAed with the fix in mind.

  This is the preferred mode of operation for this forum,
  IMO. Backporting was the most valuable service coming from RH
  updates and that is what users will be looking for.

o do it the easy way: Usually there will be a recent upstream version
  fixing the problem, grab the srpm from rawhide, QA it and stuff it
  into RH7.3 updates.

  Obviously this is fast, and better than nothing if nobody does the
  true work above.

The latter method is something most external repos do. For instance
ATrpms provides upgraded, not backported (!) versions of rpm, yum and
apt for RH7.3 upwards. Again I don't think that should be legacy's
mode of operation. I expect highly conservative methods
here. Otherwise you could just as good submit packages to ATrpms.
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20040107/e78cc026/attachment.sig>