[arch-general] Upstream bugs, patches
Hi! I'm new to this list, and my English is far from perfect, please tolerate it ;-) I am/was a big fan of ArchLinux, I'm using it from 0.5 version, I also made some little contributions to pacman, but now I noticed some tendencies which I cannot accept. So I would like to hear the official "standpoint" about a certain question, before I may drop my good old distro. I also think that this question is important to all end-users. (Aaron:) I know that I'm not popular here, but I hope that you won't answer "against me" ;-) Some foreword (sorry, maybe off, I would like to manipulate thoughts :-D): Basically I think that principles are _not_ rules. So things like KISS and "vanilla packages" are good for defining ourselves in one sentence (in wikipedia for example), but I don't really understand reasoning like "foo violates KISS" (IMHO the reasoning should say, _why_ it worth applying KISS here.). When I _describe_ myself as liberal, I won't deduce my acts from this "rule"... (theoretical example). So the question: Do/Should Archlinux packagers apply unofficial or merged-but-not-yet-released patches to fix an existing _bug_ of a released package? An example: http://bugs.archlinux.org/task/5861 This is quite an old bug, and we are just waiting and waiting... If the answer no, do packagers forward the bug to the official developer or the end-user should forward his discovered bug? An other small example, which is much less important; but I think this belongs to the same "category", the reasoning is much more mysterious to me, since the "patch" clearly cannot break anything here: http://bugs.archlinux.org/task/10307 This was closed 4 minutes after opening, so I couldnot discuss it (I wanted to revert my last sentence there, this is not true now, I didn't want to lie). Evince developers like that option, and they don't want to change it. (But I don't agree with them here, of course). I simply cannot imagine any reason for "won't fix" (apart from "lazyness" :-P). I'm pretty sure that "implementing" it has _no drawback_, and at least 6 users (from the number of requests) would like it. Again, it is a marginal issue (I put my evince.desktop to NoUpgrade of pacman), but I would like to understand the reason of close. Bye I hope, that I didn't hurt anybody, overall I think that AL is still one of best distros around, and I must say a big "thank you" for your work.
See. you didn't decide on one side so you scared of both :P -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
On Thu, May 01, 2008 at 10:43:29PM +0200, Nagy Gabor wrote:
Hi!
I'm new to this list, and my English is far from perfect, please tolerate it ;-)
I am/was a big fan of ArchLinux, I'm using it from 0.5 version, I also made some little contributions to pacman, but now I noticed some tendencies which I cannot accept. So I would like to hear the official "standpoint" about a certain question, before I may drop my good old distro. I also think that this question is important to all end-users.
(Aaron:) I know that I'm not popular here, but I hope that you won't answer "against me" ;-)
Some foreword (sorry, maybe off, I would like to manipulate thoughts :-D): Basically I think that principles are _not_ rules. So things like KISS and "vanilla packages" are good for defining ourselves in one sentence (in wikipedia for example), but I don't really understand reasoning like "foo violates KISS" (IMHO the reasoning should say, _why_ it worth applying KISS here.). When I _describe_ myself as liberal, I won't deduce my acts from this "rule"... (theoretical example).
So the question: Do/Should Archlinux packagers apply unofficial or merged-but-not-yet-released patches to fix an existing _bug_ of a released package? An example: http://bugs.archlinux.org/task/5861 This is quite an old bug, and we are just waiting and waiting...
If the answer no, do packagers forward the bug to the official developer or the end-user should forward his discovered bug?
An other small example, which is much less important; but I think this belongs to the same "category", the reasoning is much more mysterious to me, since the "patch" clearly cannot break anything here: http://bugs.archlinux.org/task/10307 This was closed 4 minutes after opening, so I couldnot discuss it (I wanted to revert my last sentence there, this is not true now, I didn't want to lie). Evince developers like that option, and they don't want to change it. (But I don't agree with them here, of course). I simply cannot imagine any reason for "won't fix" (apart from "lazyness" :-P). I'm pretty sure that "implementing" it has _no drawback_, and at least 6 users (from the number of requests) would like it. Again, it is a marginal issue (I put my evince.desktop to NoUpgrade of pacman), but I would like to understand the reason of close.
Bye
I hope, that I didn't hurt anybody, overall I think that AL is still one of best distros around, and I must say a big "thank you" for your work.
Just a link in case you missed it http://phraktured.net/patching-patching-patching.html First reply is mine. Greg
Just a link in case you missed it http://phraktured.net/patching-patching-patching.html First reply is mine.
OK. I suggested my preferred answer in "foreword", that we shouldn't answer this question in general, estimate the answer in every particular case instead. Some comments: AUR is one of the best thing of Arch, agreed. 'No comment' (sry): "Arch was made to work with you, not for you." Bye
On Thu, 1 May 2008 22:43:29 +0200
Nagy Gabor
So the question: Do/Should Archlinux packagers apply unofficial or merged-but-not-yet-released patches to fix an existing _bug_ of a released package? I don't see anything wrong with applying a patch, but it shouldn't just be applied and left to sit there. The patch should be sent upstream as well.
If the answer no, do packagers forward the bug to the official developer or the end-user should forward his discovered bug? Even if the answer is 'yes' I think the bug and patches should still be forwarded. In an ideal world a packager should follow the package's development upstream and have some communication with it's developers.
If there are lingering bugs, the project has become stagnant and there is no one to commit changes and release a new version then I would consider taking the package out of the repo altogether. Move it to unsupported. Another issue here is if the project has some philosophical/technical/other issues with the patch. There's no easy solution here. That's something that has to be considered on a case by case basis. If it's bad enough, someone might decide to fork. :D It's good to make upstream problems known. Users and developers should work to fix the problems from the source rather than only patching things locally. Imagine how many more users from all distros will benefit if things are patched upstream. It's the user's job as well as the developers' to bug upstream once he or she knows the facts.
Even if the answer is 'yes' I think the bug and patches should still be forwarded. In an ideal world a packager should follow the package's development upstream and have some communication with it's developers.
If there are lingering bugs, the project has become stagnant and there is no one to commit changes and release a new version then I would consider taking the package out of the repo altogether. Move it to unsupported.
Another issue here is if the project has some philosophical/technical/other issues with the patch. There's no easy solution here. That's something that has to be considered on a case by case basis. If it's bad enough, someone might decide to fork. :D
It's good to make upstream problems known. Users and developers should work to fix the problems from the source rather than only patching things locally. Imagine how many more users from all distros will benefit if things are patched upstream. It's the user's job as well as the developers' to bug upstream once he or she knows the facts.
You describe what i once thought archlinux is all about. Maybe my ideas are not so wrong after all? -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
Nagy Gabor wrote:
An example: http://bugs.archlinux.org/task/5861 This is quite an old bug, and we are just waiting and waiting...
Sometimes packagers are slow, sometimes upstream is slow. This is not so surprising, the time of open source developers is always too limited :) Putting some pressure on upstream developers might help, especially when there is an very easy fix to a very annoying issue. And in this case, it was probably easy to build your own fixed package. So no big deal.
If the answer no, do packagers forward the bug to the official developer or the end-user should forward his discovered bug?
You should probably look yourself on the upstream bug tracker to know what is going on.
An other small example, which is much less important; but I think this belongs to the same "category", the reasoning is much more mysterious to me, since the "patch" clearly cannot break anything here: http://bugs.archlinux.org/task/10307 This was closed 4 minutes after opening, so I couldnot discuss it (I wanted to revert my last sentence there, this is not true now, I didn't want to lie). Evince developers like that option, and they don't want to change it. (But I don't agree with them here, of course). I simply cannot imagine any reason for "won't fix" (apart from "lazyness" :-P). I'm pretty sure that "implementing" it has _no drawback_, and at least 6 users (from the number of requests) would like it. Again, it is a marginal issue (I put my evince.desktop to NoUpgrade of pacman), but I would like to understand the reason of close.
Again, make sure that upstream is aware of this : that many users consider this was a bad move, and that many other distro have to patch it (specifying which exact distro and providing proof / links to source packages if possible). But as you stated, this was also easy for you to fix this manually, so again, no big troubles here.
Nagy Gabor wrote:
An example: http://bugs.archlinux.org/task/5861 This is quite an old bug, and we are just waiting and waiting...
Sometimes packagers are slow, sometimes upstream is slow. This is not so surprising, the time of open source developers is always too limited :) Putting some pressure on upstream developers might help, especially when there is an very easy fix to a very annoying issue. And in this case, it was probably easy to build your own fixed package. So no big deal.
No big deal. (I've rebuilt it.) But if you also think, that it should be rebuilt, then why is sitting that buggy package in repo? I have the feeling that the main reason of "no patch" is minimizing the developer-responsibility, which is in fact understandable. To be honest, I don't like "you can do it" answers. Probably I could use LinuxFromScratch (or I could eat a spider;-), but I don't want it. I expect from my distro at least working packages. Back to the subject. I can also understand some reasons of "no-patch" viewpoint. Basically it is not a good thing, that distroX manipulates radically foo app without telling the users, that we "hacked lots of things here", and users blame the developer instead of packager. (That's why I think end-users should send bug reports to packagers; even if the package is not patched at all, a not-experienced user may not recognize that this is a packaging bug, and sends some spam to the original developers.) But I don't ask 20 patches for each packages, I ask "working packages" only, and "ratio over dogmas" in some cases. And I don't hear much complaints about the distro-patching from developers (exceptions: Jörg Schilling for example). A bit going further, I think that "patchability" is one of the main power of open source; and I see nothing wrong (fundamentally) in the common practice, that distros supply "mini-fork" packages to satisfy their users' taste in the heterogeneous linux community (some users like eye-candy others are minimalistic etc). Usually I enjoy _usable_ "vanilla" packages (that's why I am AL user). Bye
Nagy Gabor wrote:
No big deal. (I've rebuilt it.) But if you also think, that it should be rebuilt, then why is sitting that buggy package in repo? I have the feeling that the main reason of "no patch" is minimizing the developer-responsibility, which is in fact understandable. To be honest, I don't like "you can do it" answers. Probably I could use LinuxFromScratch (or I could eat a spider;-), but I don't want it. I expect from my distro at least working packages.
LFS isn't vanilla either, the goal is to get a working system in the end, so they patch when needed. http://www.linuxfromscratch.org/lfs/view/stable/chapter03/patches.html However, it's probably as vanilla as possible, quite like Arch in my opinion.
Back to the subject. I can also understand some reasons of "no-patch" viewpoint. Basically it is not a good thing, that distroX manipulates radically foo app without telling the users, that we "hacked lots of things here", and users blame the developer instead of packager. (That's why I think end-users should send bug reports to packagers; even if the package is not patched at all, a not-experienced user may not recognize that this is a packaging bug, and sends some spam to the original developers.) But I don't ask 20 patches for each packages, I ask "working packages" only, and "ratio over dogmas" in some cases.
And I don't hear much complaints about the distro-patching from developers (exceptions: Jörg Schilling for example). A bit going further, I think that "patchability" is one of the main power of open source; and I see nothing wrong (fundamentally) in the common practice, that distros supply "mini-fork" packages to satisfy their users' taste in the heterogeneous linux community (some users like eye-candy others are minimalistic etc). Usually I enjoy _usable_ "vanilla" packages (that's why I am AL user).
Again, when there is a really unusable / broken package, it's very likely not because of the vanilla philosophy, but because of the lack of time of developers. And as far as I am concerned, Arch provides working packages, so I would say it's doing pretty well overall. There are probably exceptions that confirm the rule, but that's life, nothing is perfect :)
And I don't hear much complaints about the distro-patching from developers (exceptions: Jörg Schilling for example). A bit going further, I think that "patchability" is one of the main power of open source; and I see nothing wrong (fundamentally) in the common practice, that distros supply "mini-fork" packages to satisfy their users' taste in the heterogeneous linux community (some users like eye-candy others are minimalistic etc). Usually I enjoy _usable_ "vanilla" packages (that's why I am AL user).
Again, when there is a really unusable / broken package, it's very likely not because of the vanilla philosophy, but because of the lack of time of developers. And as far as I am concerned, Arch provides working packages, so I would say it's doing pretty well overall. There are probably exceptions that confirm the rule, but that's life, nothing is perfect :)
Yes, I would like to believe, that you are right here. But the mc bug I showed you was _closed_ by reasoning: 'Implemented/Merged upstream'. And the same reasoning for this: http://bugs.archlinux.org/task/5546 Bye
On Fri, May 02, 2008 at 02:11:48PM +0200, Nagy Gabor wrote:
And I don't hear much complaints about the distro-patching from developers (exceptions: Jörg Schilling for example). A bit going further, I think that "patchability" is one of the main power of open source; and I see nothing wrong (fundamentally) in the common practice, that distros supply "mini-fork" packages to satisfy their users' taste in the heterogeneous linux community (some users like eye-candy others are minimalistic etc). Usually I enjoy _usable_ "vanilla" packages (that's why I am AL user).
Again, when there is a really unusable / broken package, it's very likely not because of the vanilla philosophy, but because of the lack of time of developers. And as far as I am concerned, Arch provides working packages, so I would say it's doing pretty well overall. There are probably exceptions that confirm the rule, but that's life, nothing is perfect :)
Yes, I would like to believe, that you are right here. But the mc bug I showed you was _closed_ by reasoning: 'Implemented/Merged upstream'. And the same reasoning for this: http://bugs.archlinux.org/task/5546
Bye
Even if it was merged upstream the mc package in extra is 2 years old. Maybe you could try requesting to replace it by the most recent snapshot. I have used it for a while and it seemed totally usable, even though i didnt test it thoroughly. Its from sometime in 2007 IIRC so chances are the patch in the bug report is part og the source. Greg
participants (5)
-
Arvid Ephraim Picciani
-
Grigorios Bouzakis
-
Loui
-
Nagy Gabor
-
Xavier