-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 R Hill wrote: > a) what would be the point of the reporter also being the verifier as > far as confirming that the bug is real and not a PEBKAC error?
Sometimes devs do clever things to their systems that end-users aren't aware of, or they test the fix logged into their machine with special priviledges, etc. So having the reporter verify would test the fix with those things out of the loop. > b) what would be the point of requiring that verification be done by a > third party if the dev the PR is assigned to can reproduce the bug > themselves? I'm assuming that this would only apply to cases where the dev has provided a fix (in most cases I assume they would have reproduced the problem). The reporter's test would have the benefits mentioned above, and if the Team Lead tested, they could review the fix for technical correctness, etc. > c) how do you propose the assignee fix the bug if they cannot reproduce > it? this may be possible in some cases, but not anywhere near the > majority. My suggestion doesn't even cover that; it assumes that the dev has provided a fix. > d) team leads lead the team, not attempt to reproduce bugs for every PR > that falls under their umbrella. to be blunt, they have much better > things to do. Is it out of the scope of the Team Lead to check that [his|her] devs are fixing things in a technically correct manner? From the "Gentoo Developer Handbook": "Team leads are responsible for organizing the developer in their team and coordinating releases and also resolving issues within the team, as well as improving products on the basis of feedback from the community." http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=5 I think a bug report qualifies as feedback from the community and verifying that a bug fix actually works would qualify as improving products. > Dear Nathan, > > In your spare time, could you please begin testing every new problem > report filed as of now for validity and tag them appropriately? This > small, incremental move should greatly improve our QA process. Thanks boo. Again, my suggestion attempts to improve the process farther down stream; the problem of validating new bugs and tagging them appropriately is a separate matter. Also, suggesting that I do all the work is silly. It suggests, to me at least, that you can't find anything wrong with what I'm suggesting, but for some reason or another you're unwilling to change your working habits. So you throw up the "if its such a good idea, you do it... ALL of it!" nonsense. Obviously, no process (including the current Gentoo bugzilla process being used daily) will work without participation from most of the people involved. There will *always* be people who disagree, and there will *always* be people who skirt the system in some way. That's just life. > Note: I am not denying there could be a (small) policy problem, I'm just > pointing out that the proposed solution is unworkable. Great! Can you think of any ways to make my idea workable? What about a completely different solution? To restate the problem: When a dev submits a fix for a bug, it should be verified and peer reviewed before the bug is marked done. Nathan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Sdc2QTTR4CNEQARAsh+AJ93PRmC0JLJlBNV3kSbFlKR2vOkOgCdEpvq 2SVJFg/G2B0sb8CXTstOGEY= =CAPL -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
