Re: Architecture usertags
On Wed, Mar 25, 2009 at 05:30:19PM +0100, Wouter Verhelst wrote:
> I thought I'd sent out this mail, but apparently I did that when I had
> just reinstalled my laptop and the mailsetup wasn't working yet. Sorry
> about that.
> Now almost a month ago, I asked Don Armstrong to create architecture
> tags in the BTS. I've always felt that such a thing would be useful,
> because often porters are unaware of architecture-specific bugs, simply
> because there's no way in the BTS to actually search for them. Having
> such an ability could make porters of a particular architecture aware of
> the issues that affect their architecture, and (where necessary) able to
> help out.
> Don suggested using usertags instead, since it is the policy of the
> maintainers of the BTS to not create new 'regular' tags anymore unless a
> usertag is in common use already. That's fine with me, but it has one
> tiny little problem: if people are unaware of the usertag, they cannot
> add it to their bugs, thereby defeating the purpose of this whole
> exercise (allowing porters to find architecture-specific bugs that they
> are unaware of). This mail is to remedy that one tiny little problem.
> I made a small proposal on the debian porters' mailinglists, which did
> not encounter any resistance (apart from the fact that some
> architectures already have a (set of) usertags that they use). It is as
> - The user to an architecture usertag should be the porters' mailinglist
> for that particular architecture. That is,
> email@example.com for powerpc-related bugs,
> firstname.lastname@example.org for arm and armel-related bugs, and so
> - The usertag should be the name of the architecture: m68k for m68k,
> powerpc for powerpc, hurd-i386 for hurd-i386, and so on (that's not
> hard, is it? ;-)
> I made a short overview of this on the wiki, at
Got an extra ch in there?
> (with permission
> from Don to write something in the /Teams/Debbugs namespace)
> Maintainers are hereby encouraged to use these usertags on any
> architecture-specific bugs they might have on their packages.