[arch-dev-public] patching
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? - P
On Thursday 11 March 2010 00:01:58 Paul Mattal wrote:
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. I am totally agree with these rules. I don't like to patch software to provides this or that feature, but we need to patch a software that does not work due a bug fixed upstream.
People can edit and rebuild packages using ABS and/or AUR. "Arch was made to work with you, not for you" [A. Griffin] :) -- Andrea
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?
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. - P
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: Submitted By: Date: Initial Package Version: Upstream Status: Origin: Description: Debian has something similar. That way we could keep track of why patches are being used. Allan
participants (3)
-
Allan McRae
-
Andrea Scarpino
-
Paul Mattal