Re: [gentoo-dev] Keywordreqs and slacking arch teams

[Rolf Eike Beer <eike@sf-mail.de>]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

> - Allowed a simple "Add keyword(s) <y..> for package <x>" interface,
>   that intelligently created an issue and a target list, and then once
>   the list was built, constantly ensured the list to be valid, or
>   determined automatically when sub-work was completed and reducing the
>   published list automatically, and then responded to potential issues
>   based on changes in git, ( as opposed to being only triggered when
>   the bug was touched )

As someone who does both keywordings and stabilizations regularly on hppa and 
sparc I think I must share a bit of my experiences:

-some arches are regularly forgotten to be CC'ed, which happens for the above 
arches quite regularly as they are exp

-if I need to do a bug at a later point when I want to newly stabilize a given 
package for a new arch it is extremely helpful if

  - the package list was not reduced on a later point because parts were 
already handled

  - arch specifications for packages are reduced to the absolute need, i.e. 
especially not given if the arch list would match the initial CC list

I use tatt for my work, and that automatically sorts out all packages that 
have non-matching package list. Sure, there could be improvements for several 
things in tatt, but that is IMHO absolutely right the way it is. So if you 
give all arches and I later decide to do the same bug on an additional arch 
then it will not do a single package.

So if you want my work easier, then
-don't forget to CC exp arches
-don't clean the package list only because packages are already done
-let tatt run on your dev box, or preferably in a new chroot yourself, on your 
package, and fix all the broken dependencies and stuff there yourself. Your 
amd64 laptop is still way faster than my crowded C8000, and doing a roundtrip 
through the bugtracker until you find time to fix it will just make you think 
of "slacking arch teams" next time.

Thanks,

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]