1.63 hardcodes path to /sbin/udevadm, whereas current stable udev installs to /bin/udevadm 1.64 fixes this problem by using `which` for determining the path, so lets stabilize it see here: http://forums.gentoo.org/viewtopic-p-7549570.html#7549570 thanks!
amd64/x86 stable (user tested it from IRC for me)
(In reply to Samuli Suominen from comment #1) > amd64/x86 stable (user tested it from IRC for me) and user report is sufficient to acknowledge if package is stable? so it solves the issue you care about, and what if it has other issues? how can you decide to stabilize a package you do not maintain?
[QA] "Moving a package from ~arch to arch is done only by the relevant arch teams." http://devmanual.gentoo.org/keywording/#moving-from-~arch-to-arch There are exceptions to that listed there, like individual arrangements and to some extent security issues; but I wonder if either of those exceptions is the case here. Per that policy, you are able to revert the commit; but first consider to give Samuli time, to state a reason as to why this stabilization is so urgent. If you don't revert, the arch teams must be contacted; it is their responsibility to ensure that the stable tree is stable and therefore widely tested, unless you (as the maintainer) have an arrangement with the arch team about that.
I do not wish to revert. However, the request for marking anything as stable, the initiation of the process cannot be of anyone but package maintainer.
amd64 lead has long ago provided this exception to everyone who is capable of testing on a stable system x86 had an exception for a while with Opfer wanting to test everything himself, but have since retired, and the developers have endorsed stabilizations by developers who can test the packages try actually doing something for qa@ and stop messing with other peoples work
(In reply to Tom Wijsman (TomWij) from comment #3) > [QA] you have to be kidding. > There are exceptions to that listed there, like individual arrangements and > to some extent security issues; but I wonder if either of those exceptions > is the case here. Per that policy, you are able to revert the commit; but > first consider to give Samuli time, to state a reason as to why this > stabilization is so urgent. because stable was broken. now it isn't. period. stop wasting everyones time.
(In reply to Samuli Suominen from comment #5) > amd64 lead has long ago provided this exception to everyone who is capable > of testing on a stable system > x86 had an exception for a while with Opfer wanting to test everything > himself, but have since retired, and the developers have endorsed > stabilizations by developers who can test the packages And how can you know if it is stable or not if you only test for specific issue resolution? Do you use the package? do you know the package? The stabilization process must be initiated by someone who knows the package the arch teams can add considerations, they cannot replace maintainers as no way can they know all packages in the level of their maintainers.
(In reply to Samuli Suominen from comment #6) > because stable was broken. now it isn't. period. stop wasting everyones time. Maintainer could have added relevant patch for stable version to fix the issue you had. The fact that you maintain udev does not give you the right to bump anything.
(In reply to Samuli Suominen from comment #5) > amd64 lead has long ago provided this exception to everyone who is capable > of testing on a stable system > x86 had an exception for a while with Opfer wanting to test everything > himself, but have since retired, and the developers have endorsed > stabilizations by developers who can test the packages > > try actually doing something for qa@ and stop messing with other peoples work That however does not mean that you can CC arches or stabilize yourself a bug for a package that you do not maintain; you're outright ignoring Alon here, policy requires you to talk with him.
(In reply to Alon Bar-Lev from comment #8) > (In reply to Samuli Suominen from comment #6) > > because stable was broken. now it isn't. period. stop wasting everyones time. > > Maintainer could have added relevant patch for stable version to fix the > issue you had. The fact that you maintain udev does not give you the right > to bump anything. no it doesn't, but stable was broken and it's an arch developer job to keep stable intact, which is exactly what i did. i tried to look for you at IRC for quick resolution, but for some reason, you weren't around that time (maybe i looked for an wrong nick, who knows) plus i've maintained laptop-mode-tools long before you were reinstated as a developer (just look at ChangeLog prior to your commits) anyways, accept my apology for not giving it greater effort to find you for quick fix, i waited for an answer in the bug for ~24 hours, and tried IRC, but failed
(In reply to Samuli Suominen from comment #6) > (In reply to Tom Wijsman (TomWij) from comment #3) > > [QA] > > you have to be kidding. No, I'm serious; are you? > because stable was broken. now it isn't. period. stop wasting everyones time. That is what package.mask is for. Period. Easy to say, stop wasting QA's time. Given that no action is expected from QA, and the necessary talk is done, this is outside our scope, please talk this out with each other and escalate this only when it is really necessary. Have a nice day. (In reply to Samuli Suominen from comment #10) > no it doesn't, but stable was broken and it's an arch developer job to keep > stable intact, which is exactly what i did. You're not an arch team member. > plus i've maintained laptop-mode-tools long before you were reinstated as a > developer (just look at ChangeLog prior to your commits) Either you maintain it, or you don't. > i tried to look for you at IRC for quick resolution, but for some reason, > you weren't around that time (maybe i looked for an wrong nick, who knows) > > anyways, accept my apology for not giving it greater effort to find you for > quick fix, i waited for an answer in the bug for ~24 hours, and tried IRC, > but failed The bug doesn't state that it is urgent, consider to note that in the future; other than that, thank you for apologizing.
Let's summarize a bit with calm :) Usually, if a developer have a stable system and does the adequate tests, is "authorized" to mark stable. Sometimes arch developer are unable to do a complete test because of e.g. lack of hardware. In such case we can just do a compile test and eventually check if the binary at least starts. In this case I guess Samuli make a compile test and as a plus an user confirms that it works. So if any of you don't trust the user's comment or does not want to considerate it, take as fact that a compile test passes and it is what we can only do in some cases. If we need to change the policy, this is the right moment. So let's see in a separate place, what QA and arch teams people think about.
(In reply to Agostino Sarubbo from comment #12) > Usually, if a developer have a stable system and does the adequate tests, is > "authorized" to mark stable. Can you please clarify if this is for packages they maintain only or in general? Samuli has done his own stabilization in more bugs for packages that Samuli maintains, that's completely fine; what happened here is different from that, ...
(In reply to Tom Wijsman (TomWij) from comment #13) > Can you please clarify if this is for packages they maintain only or in > general? From a logical perspective is general. example: - I maintain the package FOO and I'm not part of amd64. I test it and mark stable. - I do not maintain the package BAR and I'm not part of amd64. I test it and mark stable. Both process requires that I'm testing the package and mark it stable so, I don't see difference between them.
(In reply to Agostino Sarubbo from comment #14) > Both process requires that I'm testing the package and mark it stable so, I > don't see difference between them. now all you need is to define "testing".
(In reply to Alon Bar-Lev from comment #15) > (In reply to Agostino Sarubbo from comment #14) > > Both process requires that I'm testing the package and mark it stable so, I > > don't see difference between them. > > now all you need is to define "testing". the user tested more than just this one particular problem (as I explicitely asked him to give it more testing than just this) i also ran `diff` between 1.63 and 1.64 and looked what changed it was a process, done with care
and btw, Freenode: 17:33 -!- There is no such nick alonbl Do you IRC? If you had been online with that nick, you would have gotten a query message regarding this.
(In reply to Samuli Suominen from comment #17) > and btw, > > Freenode: 17:33 -!- There is no such nick alonbl > > Do you IRC? If you had been online with that nick, you would have gotten a > query message regarding this. I never discuss this specific case. You have IRC, you can send email. You can put a patch for udevadm only. You could have waited more as user could use unstable for now. There is much you could have done. I do not want to enter the discussion of this specific incident, it is irrelevant, the problem is the principal. > the user tested more than just this one particular problem (as I explicitely asked him to give it more testing than just this) when have we started take user testing as something to rely on? proxy-maintainers - ok. but users?
(In reply to Alon Bar-Lev from comment #18) > when have we started take user testing as something to rely on? not alone of course, i meant it was an additional bonus to my testing :)
(unCCing amd64 and x86 per Ago's explanations, not sure if they apply to ppc too :/)
(In reply to Alon Bar-Lev from comment #15) > now all you need is to define "testing". This is defined somewhere and btw this is not the right place to continue the discussion.
seriously, all this noise was completely unfounded to begin with. for what's it worth, i'll send a mail instead of trying to find alonbl from IRC the next time for a quick fix. all the proper steps were done and all the motives were good, aiming at improving things, and i'd say even *help the maintainer out* so his package isn't broken in stable while at the same time avoiding reverting sys-fs/udev-212-r1 to ~arch to prevent users from seeing a downgrade. i just want to add that you usually don't expect people to raise noise when you don't break anything, i'm taking the full responsibility for my commit, the stabilization, if it causes some harm, i'm all over it (fixing it) as usual :) i've actually maintained this package before alonbl (just look at ChangeLog) when it had no "real primary maintainer" and kept it from being lastrited once too. doesn't really matter to me who is in metadata.xml, i would have behaved the same way in anycase.
(In reply to Alon Bar-Lev from comment #18) > I do not want to enter the discussion of this specific incident, it is > irrelevant, [...] It leads to stable improvements, a good thing; it's not an irrelevant incident, but rather to be seen as a relevant way to have talked and learned about it. > the problem is the principal. It can be demonstrated with an example; consider how >1.64 stabilization is currently blocked as is (bug #511110), which would have been an incident that can be easily worked out by talking. Given that early Linux 3.14.x has regressions. Not that it is going to make anyone annoyed or angry, whatever happens with that; compare it to how FFmpeg 2 was masked for ages, which was a mild annoyance, but only becomes anger if it would have been forcefully masked for a lifetime...
ppc stable -- compile test only
