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

[james]

On 08/15/2016 09:25 AM, Kristian Fiskerstrand wrote:
> On 08/15/2016 03:15 PM, Dirkjan Ochtman wrote:
>> On Mon, Aug 15, 2016 at 3:03 PM, Kristian Fiskerstrand <k_f@g.o> wrote:
>>> Could you please elaborate a bit? In particular from perspective of (i)
>>> integration into current workflow, (ii) complexity in application
>>> maintenance/hosting (iii) cost/benefit considerations
>>
>> Well, I think stabilization (and, to some extent, keywording) is a
>
> Thank you for elaborating
>
>> 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.

Excellent point. In fact Mozilla posted an condensed summary of 
migrating from a tinderbox to a robust CI here [1]; and the three 
keenest takeaways from that posting are::

"1) Need to run multiple jobs-of-the-same-type at a time
  2) Build-on-checkin, not build-continuously.
  3) Display build results arranged by developer checkin not by time."


[1] http://oduinn.com/blog/2014/06/04/farewell-to-tinderbox/

What I would add is the need to think about all of the arches gentoo
supports and that the results of this WG solutions are robust for a 
diverse collection of Arches and embedded platforms.

Secondly, fundamentally include "embedded arm gentoo" into the 
discussion of the WG. Before summarizing conclusions and 
recommendations, we need to realize that Gentoo really is about a "full 
spectrum of solutions".  Spanning from the traditional 
secured-conservative server platform through the nimble 'have it your 
way workstations' to minimal (VM/Container/bare metal) all the way down 
to a gentoo embedded system, which can run on a variety of hardware 
platforms, stripped, highly optimized, resource-constrained special 
purpose devices.


A very valid postulate is:: "What/how are we to organize Arm* into 
gentoo {github; bgo ; handbook ; support}.



>
>> workflow, obviously, but I think that's a plus in this case, and we
>> could make sure we have the command-line tools to make it easy to work
>> with.
>>
>
> as long as it doesn't become a disconnect to maintainer's
> responsibilities. The state of stable tree isn't a separate issue that
> belongs with the arch teams; it is an integrated and important part of
> maintaining any package to begin with.
>
>> Development/maintenance/hosting is an issue, though it's a bit hard to
>> say something definitive about it before there's more of a plan of how
>> such a tool could work. It's enough of a pain for me that I could see
>> myself investing some time in development.
>>
>> Perhaps some kind of middle ground would be to handle this stuff in a
>> separate Bugzilla product, and then making sure we have some tooling
>> around that to better present the data.
>
> See comment in previous chapter
>
>>
>> Cheers,
>>
>> Dirkjan
>>
>
> Notes:
> [0] but I don't recall any specific policies / council meeting summaries
> on it offhand and don't have time to search but feel free to provide it
> if easily available to anyone - the last discussion I see on this was
> https://archives.gentoo.org/gentoo-dev/message/df7dee4ad61fe1c9bac866d15e0babfb
>
>
So, I guess what I'm proposing, is the lenses used for this WG should 
have one, designed for x86_64 and the other lenses specific for arm*. 
[2] That way, with only a few tweaks, these ideas should encourage 
unifying a few diverse, but very important collection of architectures 
into main line gentoo docs, trees, bugs and general dev/user 
interaction, instead of being aloof and orphaned and having incomplete 
semantics. Extension of arm needs, should make the other arches, whether 
embedded or alternative, much easier to assimilate, coherently. ymmv.

[2] https://wiki.gentoo.org/wiki/Embedded_systems/ARM_hardware_list

Flexibility, as defined by those performing the embedded gentoo work, 
should be a fundamental tenant of this WG, as defined in such a way to 
continue to encourage the fine work performed by many on the various arm 
  and other platforms.


Additionally:

[3] https://wiki.gentoo.org/wiki/Project:ARM

[4] https://wiki.gentoo.org/wiki/Embedded_Handbook

[5] https://wiki.gentoo.org/wiki/Handbook:Main_Page

{arm32 and arm64 needs should be considered, where practical within BGO}
Arm64 is already hitting Datacenters, around the globe; and is a very 
large point of excitement particularly related to Green and low-cost 
efforts.


hth,
James