allan at archlinux.org
Thu Mar 11 01:44:46 CET 2010
On 11/03/10 10:21, Paul Mattal wrote:
> On 03/10/2010 06:13 PM, Allan McRae wrote:
>> On 11/03/10 09:01, Paul Mattal wrote:
>>> I wanted to ask about how others treat patching.
>>> My understanding of our patching philosophy is:
>>> 1) Don't patch if doing so makes us un-vanilla. Users familiar with the
>>> standard behavior of software should be able to rely on our packaged
>>> versions to behave the same way.
>>> 2) If there's some major roadblock (crash, hang, data loss, chronic
>>> incompatibility), apply a reasonable patch as a workaround, as long as
>>> this kind of patch for this kind of problem has not been rejected
>>> upstream. Report the bug and patch upstream, and remove the patch from
>>> our package when upstream integrates a fix.
>>> 3) We don't maintain upstream software; we should not do a lot of work
>>> to patch unmaintained software.
>>> Is this a good summary? Or do others have differing views on some of
>>> this? Things to add?
> Hah! I actually searched for such a wiki page but did not find it. It
> sounds like it's very much in line with what I wrote, but spells out a
> few particular cases, which is very helpful.
> I was mostly concerned with determining that folks did not think we
> needed to wait for upstream to approve before patching for big issues.
> We act fast on big issue patches with our best judgment, and then accept
> upstream's judgment once it is established.
I think that falls into this category:
When a *major feature* doesn't work in the app, bug fix patches are allowed.
As long as the patch goes upstream, we can monitor its progress and make
any changes upstream decides need be done.
I was thinking that perhaps we should encourage all patches to have a
header. e.g. LFS does this:
Initial Package Version:
Debian has something similar. That way we could keep track of why
patches are being used.
More information about the arch-dev-public