| 1 |
Jason Wever wrote: |
| 2 |
<snip> |
| 3 |
> |
| 4 |
> From my perspective, if a package maintainer asks for testing and the |
| 5 |
> ability to keyword (i.e. Spanky asking me if it was OK to bump binutils |
| 6 |
> to 2.16, to which I said yes) then that is fine. However adding or |
| 7 |
> changing keywords in an ebuild for which you cannot test (regardless of |
| 8 |
> how trivial the changes are or how "portable" the programming language |
| 9 |
> of said package is supposed to be) is really where I'm looking at here. |
| 10 |
|
| 11 |
Wouldn't it be better from a QA perspective to go back to the (really) old |
| 12 |
policy of dropping anything you can't test on. I know that puts more work on you |
| 13 |
guys, but this is only going to get worse as we get more devs. Wouldn't it be |
| 14 |
better to nip this in the bud now. Maybe broaden the arch teams by giving some |
| 15 |
devs access to remote boxes. |
| 16 |
|
| 17 |
--Or-- |
| 18 |
|
| 19 |
Get every dev access to all the supported arches (some of this could probably be |
| 20 |
done with emulators of some sort, qemu or somesuch). Make them test on every |
| 21 |
arch before they change any keywords. |
| 22 |
|
| 23 |
--Iggy |
| 24 |
|
| 25 |
> |
| 26 |
> For some odd reason, trying to ensure QA (even in the nicest of |
| 27 |
> fashions) seems to result in a majority of less than positive |
| 28 |
> responses. Even recently I've had a developer get quite confrontational |
| 29 |
> with me over email when I nicely asked him not to stabilize packages for |
| 30 |
> which he could not test (even if the changes were supposedly trivial). |
| 31 |
> History has shown that we cannot depend on assuming that trivial changes |
| 32 |
> for me == works for you if we want to have some level of Q in QA. |
| 33 |
> |
| 34 |
> Cheers, |
| 35 |
> - -- Jason Wever |
| 36 |
> Gentoo/Sparc Co-Team Lead |
| 37 |
|
| 38 |
-- |
| 39 |
gentoo-dev@g.o mailing list |
Archives