Because the Makefile patch was mistakenly dropped from 0.8.0 bump, files are ending up in weird places >>> Merging net-analyzer/nethogs-0.8.0 to / --- /usr/ --- /usr/share/ --- /usr/share/doc/ >>> /usr/share/doc/nethogs-0.8.0/ >>> /usr/share/doc/nethogs-0.8.0/README.decpcap.txt.bz2 >>> /usr/share/doc/nethogs-0.8.0/Changelog.bz2 >>> /usr/share/doc/nethogs-0.8.0/DESIGN.bz2 >>> /usr/share/doc/nethogs-0.8.0/README.bz2 >>> /share/ >>> /share/man/ >>> /share/man/man8/ >>> /share/man/man8/nethogs.8 <- should be in /usr/share... --- /sbin/ >>> /sbin/nethogs <- should be /usr/sbin >>> net-analyzer/nethogs-0.8.0 merged.
Review your metadata.xml reading skills, please.
Everyone is responsible for their own commits: *nethogs-0.8.0 (10 Oct 2011) 10 Oct 2011; Jeroen Roovers <jer@gentoo.org> +nethogs-0.8.0.ebuild: Version bump.
Please make Samuli stop doing this. He's ruining the fun. He's free to ignore b-w project guidelines, the (outdated) bugzilla howto and established procedures as much as he wants, but behaving like a complete prick in unacceptable.
(In reply to comment #3) > Please make Samuli stop doing this. If you have tried talking to him about this please provide a log of your conversation. If not then please do. In case you need more information about the devrel policy you can read it at [1]. Do not hesitate to ask us questions about it if any. Thanks, Denis. [1] http://www.gentoo.org/proj/en/devrel/policy.xml
The ChangeLog entries are there for countatability, so I believe this bug was correctly assigned as well as has nothing prick'ish about it. Did I forgot a 'please' somewhere in between? If that's it. Then, please fix your own commit.
Uhm this is more to do with QA than devrel: Samuli's assignment is correct: if you as a non maintainer commit something that breaks, you should get the bug directly. Especially if you don't note a version bump request bug, an ack from the maintainer, or anything like that. Devrel, I'm asking you to disregard this issue, as from my point of view of QA, Samuli did the right thing, and your call-in looks misguided.
Comment #6: I've been in netmon for years, so how was that version bump of mine a non-maintainer commit? Also, Samuli is /not/ in netmon but has been doing non-maintainer commits to nethogs for a long while, so I see no reason why he shouldn't continue to do so and fix the error he's found himself. If he doesn't there are people on the netmon team to fix Marcelo's packages. Comment #4: As for logs of the conversation, this bug's history has all the information you need. Bugs should be assigned according to metadata.xml's tags, not "blame". Comment #6 again: As for policy saying bugs should be assigned to "perpetrators of bugs", that would be some new policy I haven't seen displayed in situ since Jakub's times and which should be considered rather detrimental to our efforts since it poisons the community of volunteers we should rather be cherishing.
Fixed in -r1. Thanks everyone.
(In reply to comment #7) > Comment #4: > As for logs of the conversation, this bug's history has all the information you > need. It doesn't. Please review the devrel policy as suggested in my comment above. It does not matter any longer for this bug but it will help in the long term as it seems you are misunderstanding devrel's role in such situations. As usual, if you have any questions do not hesitate to ask me or any other devrel person. Thanks, Denis.
Not everything was fixed from Comment #0. No reason to install the nethogs binary to /sbin, it should go in /usr/sbin.
So the Summary is incomplete?
Fixed in -r2.
(In reply to comment #6) > Uhm this is more to do with QA than devrel: Samuli's assignment is correct: if > you as a non maintainer commit something that breaks, you should get the bug > directly. > As a note I am not aware of such a policy. I think maintainers should always be at least CCed to all bug reports related to their packages. If you want Samuli's behavior to become standard practice I suggest taking this to the mailing lists.
(In reply to comment #13) > (In reply to comment #6) > > Uhm this is more to do with QA than devrel: Samuli's assignment is correct: if > > you as a non maintainer commit something that breaks, you should get the bug > > directly. > > > > As a note I am not aware of such a policy. I think maintainers should always be > at least CCed to all bug reports related to their packages. If you want > Samuli's behavior to become standard practice I suggest taking this to the > mailing lists. Seems I read the history a little wrong as the maintainer was CCed to the bug. Sorry about the noise on that. It should be noted though that if this had come from a user it would have been assigned to maintainers according to bug wrangler rules.
I don't see a conflict with bug wrangling.. I mean, I don't pretend bug wranglers to go do forensics on who did what that changed whatever. But whenever I (or anyone else for what I care) can point out who did the change that broke a package, that's the person who gets the bug, in my view. That happens to my own bugs: if I change someone else's package, I look up in bugwranglers if there are new bugs coming due to my changes, and I assign them to _me_ with them in CC. Honestly I don't see what's the whole deal with this. As long as maintainer is CCed, who gets the bug is just a matter on whose radar it should be noted first, and if somebody caused a regression, I don't see why it shouldn't be on _their_ radar. Do you want to start ruling this one as well? Feel free to enjoy it. I find it a waste of time. Which should have been solved by a "no need to assign to me, I see it through netmon", which happens to be the kind of answer I send when somebody assign/CCs me on bugs for teams I'm part of.
(In reply to comment #15) > > Honestly I don't see what's the whole deal with this. As long as maintainer is > CCed, who gets the bug is just a matter on whose radar it should be noted > first, and if somebody caused a regression, I don't see why it shouldn't be on > _their_ radar. Do you want to start ruling this one as well? Feel free to enjoy > it. I find it a waste of time. Which should have been solved by a "no need to > assign to me, I see it through netmon", which happens to be the kind of answer > I send when somebody assign/CCs me on bugs for teams I'm part of. > The point is that I don't think there is a documented rule to do as you described. Until it becomes documented and generally known it can't be expected. As long as the only documented assigned policy is the bug wrangler policy it shouldn't be a surprise that people think that's the way things should go. Bug assignments aren't on the top of my own priorities so I have no plans to bring things this up in the near future. If QA wants people to assign to maintainers they should bring the issue up on mailing lists and eventually get the practice written in our documentation.
(In reply to comment #16) > (In reply to comment #15) > > > > Honestly I don't see what's the whole deal with this. As long as maintainer is > > CCed, who gets the bug is just a matter on whose radar it should be noted > > first, and if somebody caused a regression, I don't see why it shouldn't be on > > _their_ radar. Do you want to start ruling this one as well? Feel free to enjoy > > it. I find it a waste of time. Which should have been solved by a "no need to > > assign to me, I see it through netmon", which happens to be the kind of answer > > I send when somebody assign/CCs me on bugs for teams I'm part of. > > > > The point is that I don't think there is a documented rule to do as you > described. Until it becomes documented and generally known it can't be > expected. As long as the only documented assigned policy is the bug wrangler > policy it shouldn't be a surprise that people think that's the way things > should go. Bug assignments aren't on the top of my own priorities so I have no > plans to bring things this up in the near future. If QA wants people to assign > to maintainers they should bring the issue up on mailing lists and eventually > get the practice written in our documentation. Petteri, my reading of Diego's comment, is the following: The bug-wranglers project created a set of rules defining how to assign bugs that serve as the basic "manual" by members of the project and anyone doing general bug-wrangling work. That however, doesn't mean that individual members of that project and other members of the community don't, let alone can't, "fine-tune" their operation of bugzilla taking into account their own experience. One such case, mentioned here by Diego and Samuli, is when a person digs the author of a commit that is led to have triggered a new bug or a regression, assigning to that person the bug while cc'ing its maintainers. I have to say I agree with this "fine-tuning" and that I have adopted it too.
I'd happily bring forward my views on this unrelated subject, but I am quite well aware that it was already mentioned that this isn't the proper venue to continue this discussion, so I will not do that here.
dunno why this is still open, closing
