On Mon, Aug 15, 2016 at 3:25 PM, Kristian Fiskerstrand <k...@gentoo.org> 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
