| 1 |
Chris White wrote: |
| 2 |
>>never reassign a bug |
| 3 |
> |
| 4 |
> |
| 5 |
> 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? |
| 6 |
|
| 7 |
Yes, I'm pretty much saying that. Thinking back to the situation that prompted |
| 8 |
me to note this down, a kernel bug came in. bug-wranglers assigned it to |
| 9 |
kernel. The reporter then reassigned it to me(!?) without me even responding, |
| 10 |
with a comment like, "dsd this one is for you". Since when do our users get to |
| 11 |
choose which developer fixes their bug? I found this quite rude and replied |
| 12 |
with a (probably too harsh) comment and reassigned it back to kernel. The user |
| 13 |
then sent me an apologetic email, stating that he didn't know much about |
| 14 |
Gentoo development and asked me to explain the reassignment procedures. |
| 15 |
|
| 16 |
My response to that: Just leave reassignment to the developers (wranglers |
| 17 |
included). |
| 18 |
|
| 19 |
>>always try the testing package before reporting bug |
| 20 |
> |
| 21 |
> |
| 22 |
> Not sure what you mean by this. I'd assume they would have already tested the package in order to have hit the bug? |
| 23 |
|
| 24 |
If v3.2.1 is stable, and v3.2.2 is ~arch, and they found the bug on v3.2.1, |
| 25 |
then they should also try v3.2.2 before filing the bug. Thats all I was |
| 26 |
thinking of. |
| 27 |
|
| 28 |
>>how to apply patches in general |
| 29 |
> |
| 30 |
> |
| 31 |
> 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. |
| 32 |
|
| 33 |
I mean applying patches using patch. So yes, kernel patches would be included |
| 34 |
under that. And I imagine there are many situations (for non-kernel stuff) |
| 35 |
where using patch is easier than epatch. |
| 36 |
|
| 37 |
For example, to add a patch to a small ebuild package, you can either create |
| 38 |
an overlay, copy the ebuild over, modify the ebuild to add epatch (this |
| 39 |
involves being able to find the right function in the ebuild, possibly even |
| 40 |
_creating_ a src_unpack function, requiring a lot of knowledge from the user), |
| 41 |
make a filesdir, put patch in filesdir, emerge. |
| 42 |
|
| 43 |
Or: |
| 44 |
|
| 45 |
cd /usr/portage/blah/blah |
| 46 |
ebuild blah.ebuild unpack |
| 47 |
pushd /var/tmp/portage/blah/work/blah |
| 48 |
patch -p1 /path/to/patch |
| 49 |
popd |
| 50 |
ebuild blah.ebuild merge |
| 51 |
|
| 52 |
I think the latter version is easier since it doesn't require as much |
| 53 |
background knowledge. And the patch technique is useful to know for if you |
| 54 |
need to patch a kernel or something like that. |
| 55 |
|
| 56 |
Daniel |
| 57 |
-- |
| 58 |
gentoo-dev@g.o mailing list |
Archives