Re: [gentoo-dev] Re: Improving the stabilisation process - part 1

[Kent Fredric]

On Fri, 25 Nov 2016 20:05:55 +1100
Michael Palimaka <kensington@g.o> wrote:

> I'm not sure what you mean. A standardised format and a bot to repoman
> check lists in this format is part of my original post.

Ah. I didn't take enough care reading it and mostly replied on the earlier part.

Good to see we reached similar conclusions through different avenues.

(NB: I find "too long didn't read" coming at the bottom of a post not too productive
because people who feel an article was too long to read tend to not read to the bottom
just in case somebody put a TL;DR there. I always find that data to be better presented
head-first, in a "read this first to get the general gist of it, then keep reading if you care
about details" format, that way you hit your target audience sooner)


> > But at this point we're dove tailing good ideas into a fundamentally limited system
> > where we probably should have some dedicated interface (and tools) to automate and
> > verify these things.
>
> A dedicated portal for handling this type of thing would of course be
> preferable, and work is ongoing on such a tool. However, completing and
> rolling out such a system could take a very long time. Improvements to
> the stabilisation process via Bugzilla can be rolled out in very little
> time.
>
> Let's not block incremental progress in favour of a perfect solution
> that doesn't exist yet.

Agreed. I'm fine with this as a concept as an initial staging.

> >
> > Automating the *tests* is a contentious idea to some extent, but I doubt we'd see opposition
> > for the idea of "throw repoman at it at least and make sure it doesnt' barf"
>
> That depends on how you define 'test'. This proposal (part 1) deals
> exclusively with repoman, primarily to make sure that we don't waste
> time working on requests where the maintained failed to include all
> required atoms.
>
> A future proposal will certainly involve fully-automated build testing
> of all requests, allowing effort to be better focused on runtime
> testing. I'm unsure how that could be controversial.

I'm not saying *I* have a problem with this, but I've gotten the over-all vibe
from some people that "autostabilizing all the things is bad" and I wanted to demark
this action as being somuch the opposite of that that even those people are unlikely to complain.

Because the subset of tests that only prove *repoman* integrity can't ever be
imagined sufficient in themselves to mark anything as "stable" or "working",
and so it forces people somewhere to do due diligence manually.

Hence, the general vibe is the fear that the abundance of automation will usurp
due diligence as people use that automation as the *only* indicator of "do we flip the flag" or not.