Gentoo Archives: gentoo-dev

From: Dirkjan Ochtman <djc@g.o>
To: Gentoo Development <gentoo-dev@l.g.o>
Subject: Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)
Date: Mon, 15 Aug 2016 18:24:58
In Reply to: Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree) by Kristian Fiskerstrand
1 On Mon, Aug 15, 2016 at 3:25 PM, Kristian Fiskerstrand <k_f@g.o> wrote:
2 >> very different process from handling bugs and feature requests. It
3 >> would be great if we had tooling that focuses on these instead of
4 >> trying to fit into the bug tracker. It would entail a different
5 >
6 > I'm not sure I agree on this point, my perspective is the state of the
7 > stable tree is exactly dependent on it being considered as part of the
8 > regular workflow of developers, which has at least been implied in the
9 > past[0] - resulting in e.g InVCS.
10 >
11 > Part of the discussion in that case is the number of developers running
12 > full testing (~arch) and might not care too much about the state of the
13 > stable tree, and having stabilization as part of the specific workflow
14 > will help the state of the stable tree by requiring the developer to
15 > care about it.
17 Ah, right. My perspective is mostly coming from the impression that
18 most developers don't seem to care much for the stable arch trees;
19 whereas I run stable with only a few exceptions, mostly for things
20 that I maintain myself.
22 The other angle here is that, for packages written in C/C++ at least,
23 it seems dangerous to assume that the package will just work on
24 non-x86 architectures (and I've even encountered packages where
25 upstream is somewhat hostile to 32-bits x86). If that is the case, and
26 assuming that maintainers do not have access to hardware for the other
27 architectures, then I'm not sure how much sense it makes to involve
28 the maintainer in the process of tracking stability for their package
29 on these other architectures, except insofar as explicitly requested
30 by the arch team.
32 To frame it differently, I think this whole discussion is very
33 different for amd64/x86 (which most packages are developed for) vs
34 pretty much every other architecture. The point is, it doesn't seem to
35 be a good idea to make people responsible for things that they're very
36 much not intrinsically motivated to care for, and making maintainers
37 care for keywording/stabilization on non-convential arches is tricky
38 from that perspective.
40 Cheers,
42 Dirkjan