[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: buildd/porter/maintainer roles again

On Wed, 14 Jul 2010, Aurelien Jarno wrote:
> What we really need here is the push method.

There's nothing stoping porters from pulling the status of bugs which
need to be handled by the porters and forwarding them to their mailing
list; since the maintainer of the psuedopackage would presumably be
set to the porters mailing list, messages to those bugs would arrive
there too.
> While what your offer probably answers to this problem, I would be
> more happy with something based on tags as it is already for the
> security bugs. OTOH I don't know about the internals and haven't
> thought in details about the advantages and drawbacks of each
> method. I would already be happy with pseudo packages.

It's possible to provide another tag specific mailing list, but this
requires code changes. It honestly doesn't make a difference to me
which is done; psuedopackages would just be slightly faster to roll
out and more obvious.

> I think on the contrary that we should have the same and easy method
> on all architectures, so that we can have this method recorded
> somewhere for package maintainers. If we have different and complex
> methods (like we already have with a few user tags for some
> architecture), people never apply them.

Whatever mechanism is used, porters have to be happy with it, and have
to use it. If having porters happy and using it means different
mechanisms, that's fine. A single one would be optimal, but only if 
there's enough agreement behind it.

The workflow should look something like this:

1) message goes to porter mailing list: [This bug #nnn looks like a
arch-specific bug]

2) porters reassign/tag the bug to indicate that they've seen it, and
agree that it is an arch-specific bug

Don Armstrong

I never until now realized that the primary job of any emoticon is to
say "excuse me, that didn't make any sense." ;-P
 -- Cory Doctorow

http://www.donarmstrong.com              http://rzlab.ucr.edu

Reply to: