Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[Dirkjan Ochtman]

On Mon, Aug 15, 2016 at 3:25 PM, Kristian Fiskerstrand <k_f@g.o> wrote:
>> very different process from handling bugs and feature requests. It
>> would be great if we had tooling that focuses on these instead of
>> trying to fit into the bug tracker. It would entail a different
>
> I'm not sure I agree on this point, my perspective is the state of the
> stable tree is exactly dependent on it being considered as part of the
> regular workflow of developers, which has at least been implied in the
> past[0] - resulting in e.g InVCS.
>
> Part of the discussion in that case is the number of developers running
> full testing (~arch) and might not care too much about the state of the
> stable tree, and having stabilization as part of the specific workflow
> will help the state of the stable tree by requiring the developer to
> care about it.

Ah, right. My perspective is mostly coming from the impression that
most developers don't seem to care much for the stable arch trees;
whereas I run stable with only a few exceptions, mostly for things
that I maintain myself.

The other angle here is that, for packages written in C/C++ at least,
it seems dangerous to assume that the package will just work on
non-x86 architectures (and I've even encountered packages where
upstream is somewhat hostile to 32-bits x86). If that is the case, and
assuming that maintainers do not have access to hardware for the other
architectures, then I'm not sure how much sense it makes to involve
the maintainer in the process of tracking stability for their package
on these other architectures, except insofar as explicitly requested
by the arch team.

To frame it differently, I think this whole discussion is very
different for amd64/x86 (which most packages are developed for) vs
pretty much every other architecture. The point is, it doesn't seem to
be a good idea to make people responsible for things that they're very
much not intrinsically motivated to care for, and making maintainers
care for keywording/stabilization on non-convential arches is tricky
from that perspective.

Cheers,

Dirkjan