On Mon, 2022-11-07 at 19:23 -0500, Rich Freeman wrote:
> On Mon, Nov 7, 2022 at 6:16 PM Sam James <s...@gentoo.org> wrote:
> > 
> > > On 7 Nov 2022, at 06:07, Oskari Pirhonen <xxc3ncore...@gmail.com> wrote:
> > > 
> > > On Sun, Nov 06, 2022 at 11:37:24 +0100, Piotr Karbowski wrote:
> > > > I would be in favour of stepping up the social contract and actually
> > > > prohibiting this kind of things, we had that before too, the nattka you
> > > > mgorny wrote is replacement for old bugzilla bot that was ...
> > > > closedsource and perished, though nattka now have way more features than
> > > > the old thing ever had.
> > > 
> > > As a user, I think it would be really cool if there was a requirement
> > > that all infra and infra-adjacent stuff was free software.
> > > 
> > > I feel like I've read that Debian already has something like this. While
> > > doing some quick searches I didn't find a full-on requirement, but all
> > > their infra bits I did find were powered by free software. The most
> > > relevant ones being buildd [1] and debci [2]. Additionally, the debci
> > > docs has inctructions on reproducing tests yourself [3] which is a nice
> > > extra IMO.
> > 
> > Gentoo has 
> > https://www.gentoo.org/get-started/philosophy/social-contract.html.
> 
> [...]
> 
> I think the key is something that was brought up earlier in the
> thread: is this causing problems?

We're talking about handling arch testing and not tinderboxing
in general but yes, this is causing problems.

If someone's running automation that takes care of a significant portion
of arch testing, it effectively leads to monopolized arch testing. 
Other arch testers don't need to do anything, so they eventually stop
paying attention and everyone assumes "X will take care of it anyway".

Now, the first problem is the bus factor.  If X stops doing arch
testing, requests pile up.  It takes time before others resume their
work.  If the software used to do the automation was proprietary, others
have to start over.  Of course, this is better now that we have
an alternative.

The second problem is that we don't really know *how* things are
processed.  As I've said, it happened to me before that stablereqs were
ignored for months.  My guess is that the automation couldn't figure out
how to process them, so it skipped them, silently.  I still don't know
what was the problem, or how to avoid it in the future.  If the code was
public, I could try figuring it out and perhaps even fixing it.

-- 
Best regards,
Michał Górny


Reply via email to