Re: Maintainers, porters, and burden of porting [and 1 more messages]

[Kurt Roeckx <kurt@roeckx.be>]

On Wed, Aug 31, 2011 at 02:52:53PM +0100, Ian Jackson wrote:
> Let me make an alternative proposal:
> 
>  * The root cause bug in the BTS would be given a special tag
>    ("arch-blocker:<arch>" or something).  I will call such a bug which
>    is open and has existed in this state for 30 days a "ripe arch
>    blocker for <arch>".
> 
>    Bugs in other affected packages are marked as blocked by the root
>    cause bug.  These bugs, and the arch blocker itself, may be RC, or
>    not, as appropriate.  Let us say "ripe arch bug" to mean "ripe arch
>    blocker, or bug blocked by a ripe arch blocker".

If there is a bug in say eglibc on only arch, and considered to be
RC on that arch, would you then lower the severity of that bug,
and use this new tag to indicate it's RC only on that arch?

This could be useful for arches that are not being considered for
a release, but I don't see the point in doing the same for if it's
currently still considered for a release.  If the bug already
affects testing it will migrate anyway.

But tracking bugs that way might also be useful to see if we
should consider that the arch should be part of the next release
or not.

>    The effects would be:
> 
>     1. Any ripe arch bug is ignored for the purposes of testing
>        propagation.

If they already affect testing, it will already be ignored
anyway.

>     2. For a package with an RC ripe arch bug for <arch>:
>       (i) <arch> will be ignored for testing propagation

So such bugs would automaticly have an effect on release
migration, while this is not something the release team
decides itself.  Or do you only mean that package will
be ignored and can move testing anyway?  Or they can't
move to testing?

>       (ii) no builds will be attempted by <arch> buildds,

You mean we completly stop building anything for $arch?  Or
only the packages that are affected by it?  Other than wasting
some buildd time, I don't see the harm in building things most
of the time.

>            automatic tests may be skipped on <arch>, etc.
> 
> The workflow would be as follows:
> 
>  * If a package has an arch-specific bug, the root cause needs to be
>    identified, by collaboration between porters and maintainers.  This
>    process should be driven by the maintainer.
> 
>  * Once the cause has been identified:
> 
>     - If the root cause is elsewhere, a bug needs to be filed bug
>       against that other package.  If such a bug already exists, the
>       maintainer of the first package can simply mark their bug as
>       blocked by the arch blocker.  This will allow their package to
>       migrate unless the arch blocker is new enough.
> 
>       If no such bug already exists, the maintainer should file a bug
>       against the appropriate package (toolchain or libc, perhaps),
>       and immediately tag it as an arch blocker.

You can just reassign the bug and mark it as affecting an other
package.  There is no need to have 2 bugs open for the same
problem.


Kurt