Sorry folks, I've read too many thoughtless comments by package maintainers here, and the last one is by Jeoren Roovers in http://bugs.gentoo.org/show_bug.cgi?id=239083. I don't have any particular history on Jeoren, neither did I have a look at his other comments made here, but I have simply seen this behaviour to often and don't want to see it again. Telling the user to just "emerge world" should be considered a serious fauxpas, especially with the remark that "we don't support odd combinations of ancient packages ...". Did Jeoren realize that xorg-server-1.4.2 (and any newer version) is still ~keyworded? This is nothing but disrespectful to the bug reporter, again especially in this case where he has provided significant insight into the problem. Please remove Jeoren as Bug Wrangler. Optionally, send the anti-"emerge world" inquisition squad.
I don't think we would consider removing anyone after one offense. I agree he should have probably routed the bug to the xorg maintainer. I have not looked at the sources for that bug; but I imagine his statement is that the version numbers are not defined because you have older headers related to your kernel, your glibc, or some other package and it is not really Gentoo's plan to have ebuilds in the tree work with things that old. However I still think it is the X11 herds call. If you are concerned about it please re-open the bug and ask the x11 herd to be CC'd so they can comment (as it is their package). -Alec
Wow, this is great fun. I reopened the bug report this one now depends upon. Let's see where it goes.
Btw, any bug report's Summary should describe a problem, not a solution. :)
Of course, filing a request to remove someone because of a single mishap, is nothing but an overreaction. I was very aware of that and I hope I made that clear with my remark that there is no particular bad history about Jeoron. But on the other hand, Gentoo is usable most of the time so nobody really spends hours in the bugtracker that there are pleantyful opportunities to start any personal record on anyone. My intention with filing this bug was to generally get rid of the concept of some developers that it is ok to blame compile errors on odd user package combinations. Gentoo is very flexible and odd user package combinations are not an exception but the rule and that should be considered a good thing. Playing nicely with packages from overlays, manually installed packages, or experimental/modified ebuilds, is probably too much to ask for, but notice this wasn't with bug #239083. However, Jeoren's approach, namely just upgrade, is of course the right one as nobody expects him to fix every single upstream bug. But his and many other devs implementation of the upgrading idea is wrong. "emerge world" is a really painstaking process and personally I try to prolong this as long as possible, simply because in the last half decade of using Gentoo "emerge world" always caused more problems than it solved. The right implementation of upgrading the environment in which packages are build is clearly a proper DEPENDS list. That's what this field is made for. I would even be ok with too much precaution in this case. Other distributions are usually much more conservative when it comes to estimating the dependencies. The bugtracker gives out some good advice to the user before filing a bug (search the bugtracker whether the bug was already filed, try to get a reproducible bug, etc..), to reduce the workload of the developer. I would like to see a similar _informal_ advice but not for users but for developers to reduce the workload of users, or at least ensure that they don't waste their time on the bug tracker. This advice would in my opinion include "Don't tell the user to emerge world".
Is this going anywhere? Comment #1 speaks of "one offense", comment #4 jumps on the bandwagon calling it "a single mishap". Please get an orderly lynch mob organised or stop the parade. Unless the Summary is changed, I won't have anything to do with this bug report, I won't explain what my side of the actions on bug #239083 is, and I won't see the end of this. Good luck trying to remove me as bug wrangler. Re-CC me when you've figured it all out.
Unlocked at Rej's request.
Thanks. :)
Unfortunately it isn't that easy. Just stating "I won't explain myself" is not enough to resolve this issue. It provokes exactly the opposite, it makes the issue worse. Jeroen should definitely be removed if he feels no need to explain any of his actions. Again, "emerge world", "it's your fault" fails to take responsibility for the packaging mess. Unless -- as described in bug report 239083 -- portage implements an auto-upgrade feature for packages versions that ebuilds are no longer in the portage tree (as paludis does) it is unacceptable to brand packaging failures with respect to dependencies as user error. Sorry folks, I probably misunderstood Gentoo as a serious Linux distribution, as something that I can install on a wide range of machines, that I don't need to babysit every week, that I can leave alone for _more_ than a year, and still trust that "emerge mypackage" works properly when called for duty. The point is that Gentoo's packaging quality is way below the level it was 5 years ago, that emerge world NEVER works, and always means iteratively fighting with a lot of crappy issues on the way. The bug wranglers attitude towards bugs that help emerging packages cleanly must change. Ubuntu is much more mature with respect to upgrading. No, please don't get childish and recommend me to use Ubuntu instead. That's not what I plan to do. I want to actively improve the distribution that I'm using since half a decade. I deeply regret that I spent time on tracking Bug 239083. The result is exactly zero from that effort. It is a pure waste of time on my time budget. Please remove people from bug wrangling that are incompetent to grasp the long-term problems of improperly handling user relations. This includes Rémi Cardona. He fails to understand that his not-my-business (bug closed without any ebuild changes) approach is making Gentoo a baby-sitter's distribution.
(In reply to comment #8) > Please remove people from bug wrangling that are incompetent to grasp the > long-term problems of improperly handling user relations. This includes Rémi > Cardona. He fails to understand that his not-my-business (bug closed without > any ebuild changes) approach is making Gentoo a baby-sitter's distribution. Hey listen "buddy". I will not stand there and let you insult myself and others. Gentoo is a community effort, meaning it's a two-way street. We try to do our best to fix bugs, but in return we expect users to do sensible things with their systems when they ask for help. That includes proper updating of their systems. As for the linked bug, I didn't change any ebuilds because it is useless to do so. A proper update of the system will fix the issue. IMHO, it's a reasonable assumption. User Rel will note that as part of the Gnome Herd, I've been asking for users to update their systems ever since I've been a dev. Up until today, no-one has ever complained about me and others asking this. Clemens, as you may have noticed, Xorg is a mess. Hundreds of packages, dozens of use flags, thousands of possible combinations. I'll let you do the math, it's easy enough: we can't test for _every_ single possible situation. Now, before you start calling anyone else incompetent, please take a long hard look at _yourself_. Jeroen and I have handled this bug like any other and yet you're the first one to complain. And for the record, I feel Jeroen has done an outstanding job these past few months with regards to bug wrangling. It's a tiresome job for which he should be commended. Let's just hope you come to your senses and realize how silly this whole issue is.
Frankly, I do not feel that I have insulted anyone. As a matter of fact, and if you don't get immediately, look at my arguments, "emerge world" is the wrong answer and it's by no means a reasonable assumption (see my argument baby-sitting arugment above, I won't repeat it here). Regarding your insult remark: Your response to 239083 feels like an insult to ME -- not the opposite. I spent my time to help you to create a proper ebuild, to improve packaging, and make the problems of saufnix@gmx.at go way. That's what communities and collaboration is about. But your reaction shows no community attitude. You overruled and rejected a contribution that makes problems go away with a single line of code. I rather hope you start to open your eyes and see what is actually going on here. "emerge world" is an invalid answer. Get your packaging information and/or packaging tools (paludis) right. Don't blame it on the user. And if someone dares to come along and tell you that, don't feel insulted. (I promise good will, but even then I can not guarantee that I will respond further to this if the next comment again fails to bring up proper arguments and reasons for baby-sitting. Therefore I would like the following as final note to the "HRM dep": I still insist any bug wrangler to be removed from the frontline that shows such an attitude.)
8(In reply to comment #8) > Unfortunately it isn't that easy. Just stating "I won't explain myself" is not > enough to resolve this issue. It provokes exactly the opposite, it makes the > issue worse. Jeroen should definitely be removed if he feels no need to explain > any of his actions. I think he doesn't need to explain because he thinks something is obvious and you disagree. I believe Jer is of the mind that Gentoo and the gentoo-x86 tree are designed to be updated on a fairly regular basis and a failure to keep packages up to date will cause package failures like the one you reported. I believe Jer thinks it is not our job to fix these failures as the tree is currently organized around the current set of packages, not the set of packages N years ago; we do not typically modify the tree to support older packages. Does that make more sense? He is telling you to rebuild for this reason. (I'm not asking if you agree, merely to see his point of view). > > Again, "emerge world", "it's your fault" fails to take responsibility for the > packaging mess. Unless -- as described in bug report 239083 -- portage > implements an auto-upgrade feature for packages versions that ebuilds are no > longer in the portage tree (as paludis does) it is unacceptable to brand > packaging failures with respect to dependencies as user error. From our point of view it is your fault that it broke; since it doesn't break with an up to date system and our solution is to *upgrade your system*. If you can't do that, then I'm sorry and you can fix it yourself. > > Sorry folks, I probably misunderstood Gentoo as a serious Linux distribution, > as something that I can install on a wide range of machines, that I don't need > to babysit every week, that I can leave alone for _more_ than a year, and still > trust that "emerge mypackage" works properly when called for duty. While experiences with Gentoo vary, I would not call Gentoo a Serious Linux Distribution that never requires maintenance if you continue to sync the tree because *that is not how it is designed to be used*. You would probably be fine with a portage tree snapshot from two years ago and a bunch of two year old packages. The expectation that you can have a two year old system and just upgrade from one package to another with no problems is unfounded. If you have ever say; backported a package from a testing version to a stable version it may be more obvious that there are often complications that need to be fixed. > > The point is that Gentoo's packaging quality is way below the level it was 5 > years ago, that emerge world NEVER works, and always means iteratively fighting > with a lot of crappy issues on the way. The bug wranglers attitude towards bugs > that help emerging packages cleanly must change. Gentoo did have better packages five years ago. I disagree on some of your other statements (saying never is generally a bad road to take, for instance). Certainly things have gotten worse and I expect USE dependencies to assist in this situation. However the complexities of the packages has probably increased 3-5 times what it used to be and we have done a poor job of mitigating this complexity. > > Ubuntu is much more mature with respect to upgrading. No, please don't get > childish and recommend me to use Ubuntu instead. That's not what I plan to do. > I want to actively improve the distribution that I'm using since half a decade. I hear upgrading between major releases of Ubuntu is a blast; which is essentially what you are trying to do. At my place of employment we don't even try; we just reinstall machines ;) > > I deeply regret that I spent time on tracking Bug 239083. The result is exactly > zero from that effort. It is a pure waste of time on my time budget. I'm sorry to hear that; but we typically don't incorporate changes to ensure in-tree stuff works with older unsupported stuff. > > Please remove people from bug wrangling that are incompetent to grasp the > long-term problems of improperly handling user relations. This includes Rémi > Cardona. He fails to understand that his not-my-business (bug closed without > any ebuild changes) approach is making Gentoo a baby-sitter's distribution. > Noted. The only action item I see coming out of this is that when bugwranglers get into disagreements with users they should consult with the package maintainer. Getting into spats with users is a waste of time and it is frustrating (and then I have to deal with bugs like this one ;p). Act reasonably; contact the package maintainer (add them to CC is probably sufficient) and a comment to say 'hey, we disagree on this, please chime in). In the end the maintainer has final say and it is much more difficult for someone to argue against two reasonable people than one person acting unreasonably. I will wait for the bugwranglers to comment on this critique and if they approve we can add it to the bugwrangler documentation. If you have any specific suggestions to improve bugwrangling that don't involve removing the tireless volunteers who staff these positions I'm all ears. -Alec
Portage 2.1.2_rc3-r7 (default-linux/x86/2007.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15 i686) (In reply to comment #8) > Again, "emerge world", "it's your fault" fails to take responsibility for the > packaging mess. Unless -- as described in bug report 239083 -- portage > implements an auto-upgrade feature for packages versions that ebuilds are no > longer in the portage tree (as paludis does) Your reasoning is plain ridiculous - it was the ancient portage version that had me ask you to upgrade. You weren't even using the current or testing version of portage and yet you turned the matter into a feature request for a future version.
(In reply to comment #11) > The only action item I see coming out of this is that when bugwranglers get > into disagreements with users they should consult with the package maintainer. This is the norm (and has been for years). I am going to add a bugzilla user page to the bug-wranglers project[1] and I might just include this bit of common sense. > Act reasonably; contact the package maintainer (add them to CC is probably > sufficient) and a comment to say 'hey, we disagree on this, please chime in). > In the end the maintainer has final say and it is much more difficult for > someone to argue against two reasonable people than one person acting > unreasonably. I will wait for the bugwranglers to comment on this critique and > if they approve we can add it to the bugwrangler documentation. Sounds like something for the CoC[2] to me. [1] http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml [2] http://www.gentoo.org/proj/en/council/coc.xml
(In reply to comment #12) > Portage 2.1.2_rc3-r7 (default-linux/x86/2007.0, gcc-3.4.4, glibc-2.3.5-r2, > 2.6.15 i686) > > (In reply to comment #8) > > Again, "emerge world", "it's your fault" fails to take responsibility for the > > packaging mess. Unless -- as described in bug report 239083 -- portage > > implements an auto-upgrade feature for packages versions that ebuilds are no > > longer in the portage tree (as paludis does) > > Your reasoning is plain ridiculous - it was the ancient portage version that > had me ask you to upgrade. You weren't even using the current or testing > version of portage and yet you turned the matter into a feature request for a > future version. Please read the bug report 239083 one more time. I'm not saufnix. I'm Clemens Fruhwirth. And I'm not asking for any feature request. I'm asking for a fix (which is more easy when portage would have more features).
(In reply to comment #14) > I'm asking for a fix Allow me to sum this up for everyone: If I'm not mistaken, you would like for us to add support for packages which are no longer in portage. As far as I know, it is "standard" Gentoo policy to only support in-tree packages, but to make sure there are working upgrade paths for at least a year. Furthermore, as the Gentoo Handbook clearly states, users should update their systems : "To keep your system in perfect shape (and not to mention install the latest security updates) you *need* to update your system regularly." [1] (Emphasis mine) It is those elements, and only those, that lead me to close bug #239083 as INVALID, since there was, in my opinion, nothing to fix per se. I hope that clears up Jeroen and my own actions. [1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#book_part2_chap1__chap3_sect5
(In reply to comment #15) > (In reply to comment #14) > > I'm asking for a fix > > Allow me to sum this up for everyone: > > If I'm not mistaken, you would like for us to add support for packages which > are no longer in portage. Sorry to ruin the rest of your argument, but no, I don't want support for packages which are no longer in portage. I don't want xorg-server-1.4.2 to compile cleanly with util-macros-1.10. I want that when I compile xorg-server-1.4.2, util-macros are automatically upgraded to 1.15, as building with 1.10 fails. Again, I do not care whether xorg-server lists this build dependency manually or if portage notices that there are some obsolete (=not in portage anymore) packages on the systems as dependencies and upgrades them alongside "emerge xorg-server". The fundamental difference between the behaviour above and your recommended fix "emerge world" is that "emerge world" also upgrades packages which are not needed for my goal to have 1.4.2 of xorg-server. So the "emerge world" strategy is everything else but conservative here (the practical problem with non-conservative upgrade strategies is that we definitely have QA issues with gentoo ebuilds). Therefore I like a conservative upgrading strategy: only force the user to upgrade the things that are really really necessary and leave the rest along. I definitely don't want to be forced to upgrade apache just because portage is not able to detect obsolete deep dependencies and I'm therefore forced to "emerge world", because I don't have time or desire to poke around manually (like I did in bug 239083).
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > I'm asking for a fix > > > > Allow me to sum this up for everyone: > > > > If I'm not mistaken, you would like for us to add support for packages which > > are no longer in portage. > > Sorry to ruin the rest of your argument, but no, I don't want support for > packages which are no longer in portage. I don't want xorg-server-1.4.2 to > compile cleanly with util-macros-1.10. I want that when I compile > xorg-server-1.4.2, util-macros are automatically upgraded to 1.15, as building > with 1.10 fails. So here is what I would recommend. If you want portage to upgrade your packages in this manner (where it would upgrade util-linux-1.10 to util-linux-1.15 because 1.10 is no longer in the tree) you should file a new bug, state the use case you want in the comments, and file it to "Portage Development" product. The guy who writes portage is a surprisingly reasonable fellow and he may agree with your request and implement it in a future version. > > Again, I do not care whether xorg-server lists this build dependency manually > or if portage notices that there are some obsolete (=not in portage anymore) > packages on the systems as dependencies and upgrades them alongside "emerge > xorg-server". Manually setting lower bounds on dependencies is a process that requires significant manpower; so I do not expect that solution to scale or happen to everything in the tree. (I did it for nis-utils for a bit and it was kind of annoying.) > > The fundamental difference between the behaviour above and your recommended fix > "emerge world" is that "emerge world" also upgrades packages which are not > needed for my goal to have 1.4.2 of xorg-server. So the "emerge world" strategy > is everything else but conservative here (the practical problem with > non-conservative upgrade strategies is that we definitely have QA issues with > gentoo ebuilds). > > Therefore I like a conservative upgrading strategy: only force the user to > upgrade the things that are really really necessary and leave the rest along. I > definitely don't want to be forced to upgrade apache just because portage is > not able to detect obsolete deep dependencies and I'm therefore forced to > "emerge world", because I don't have time or desire to poke around manually > (like I did in bug 239083). > Sounds good, just need to get you talking to the right folks ;) -Alec
I'm closing this bug as I don't see anything else to do here. As I think Jeroen has been doing a great work with bug-wrangling, I'm closing this as wontfix.
