Chris White wrote: >>never reassign a bug > > > Ok, I have a section on how to re-assign the bug to the maintainer if you're > the reporter, so you don't want that at all is what you're saying? Just let > bug-wranglers handle it?
Yes, I'm pretty much saying that. Thinking back to the situation that prompted me to note this down, a kernel bug came in. bug-wranglers assigned it to kernel. The reporter then reassigned it to me(!?) without me even responding, with a comment like, "dsd this one is for you". Since when do our users get to choose which developer fixes their bug? I found this quite rude and replied with a (probably too harsh) comment and reassigned it back to kernel. The user then sent me an apologetic email, stating that he didn't know much about Gentoo development and asked me to explain the reassignment procedures. My response to that: Just leave reassignment to the developers (wranglers included). >>always try the testing package before reporting bug > > > Not sure what you mean by this. I'd assume they would have already tested > the package in order to have hit the bug? If v3.2.1 is stable, and v3.2.2 is ~arch, and they found the bug on v3.2.1, then they should also try v3.2.2 before filing the bug. Thats all I was thinking of. >>how to apply patches in general > > > I need a clearer example of this. Do you mean applying kernel patches? Most > users will just need to know how to patch ebuilds and add epatch lines to > ebuilds, I'm not sure of anything else. I mean applying patches using patch. So yes, kernel patches would be included under that. And I imagine there are many situations (for non-kernel stuff) where using patch is easier than epatch. For example, to add a patch to a small ebuild package, you can either create an overlay, copy the ebuild over, modify the ebuild to add epatch (this involves being able to find the right function in the ebuild, possibly even _creating_ a src_unpack function, requiring a lot of knowledge from the user), make a filesdir, put patch in filesdir, emerge. Or: cd /usr/portage/blah/blah ebuild blah.ebuild unpack pushd /var/tmp/portage/blah/work/blah patch -p1 /path/to/patch popd ebuild blah.ebuild merge I think the latter version is easier since it doesn't require as much background knowledge. And the patch technique is useful to know for if you need to patch a kernel or something like that. Daniel -- gentoo-dev@gentoo.org mailing list
