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...@gentoo.org> 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
