| 1 |
On Mon, 2022-11-07 at 19:23 -0500, Rich Freeman wrote: |
| 2 |
> On Mon, Nov 7, 2022 at 6:16 PM Sam James <sam@g.o> wrote: |
| 3 |
> > |
| 4 |
> > > On 7 Nov 2022, at 06:07, Oskari Pirhonen <xxc3ncoredxx@×××××.com> wrote: |
| 5 |
> > > |
| 6 |
> > > On Sun, Nov 06, 2022 at 11:37:24 +0100, Piotr Karbowski wrote: |
| 7 |
> > > > I would be in favour of stepping up the social contract and actually |
| 8 |
> > > > prohibiting this kind of things, we had that before too, the nattka you |
| 9 |
> > > > mgorny wrote is replacement for old bugzilla bot that was ... |
| 10 |
> > > > closedsource and perished, though nattka now have way more features than |
| 11 |
> > > > the old thing ever had. |
| 12 |
> > > |
| 13 |
> > > As a user, I think it would be really cool if there was a requirement |
| 14 |
> > > that all infra and infra-adjacent stuff was free software. |
| 15 |
> > > |
| 16 |
> > > I feel like I've read that Debian already has something like this. While |
| 17 |
> > > doing some quick searches I didn't find a full-on requirement, but all |
| 18 |
> > > their infra bits I did find were powered by free software. The most |
| 19 |
> > > relevant ones being buildd [1] and debci [2]. Additionally, the debci |
| 20 |
> > > docs has inctructions on reproducing tests yourself [3] which is a nice |
| 21 |
> > > extra IMO. |
| 22 |
> > |
| 23 |
> > Gentoo has https://www.gentoo.org/get-started/philosophy/social-contract.html. |
| 24 |
> |
| 25 |
> [...] |
| 26 |
> |
| 27 |
> I think the key is something that was brought up earlier in the |
| 28 |
> thread: is this causing problems? |
| 29 |
|
| 30 |
We're talking about handling arch testing and not tinderboxing |
| 31 |
in general but yes, this is causing problems. |
| 32 |
|
| 33 |
If someone's running automation that takes care of a significant portion |
| 34 |
of arch testing, it effectively leads to monopolized arch testing. |
| 35 |
Other arch testers don't need to do anything, so they eventually stop |
| 36 |
paying attention and everyone assumes "X will take care of it anyway". |
| 37 |
|
| 38 |
Now, the first problem is the bus factor. If X stops doing arch |
| 39 |
testing, requests pile up. It takes time before others resume their |
| 40 |
work. If the software used to do the automation was proprietary, others |
| 41 |
have to start over. Of course, this is better now that we have |
| 42 |
an alternative. |
| 43 |
|
| 44 |
The second problem is that we don't really know *how* things are |
| 45 |
processed. As I've said, it happened to me before that stablereqs were |
| 46 |
ignored for months. My guess is that the automation couldn't figure out |
| 47 |
how to process them, so it skipped them, silently. I still don't know |
| 48 |
what was the problem, or how to avoid it in the future. If the code was |
| 49 |
public, I could try figuring it out and perhaps even fixing it. |
| 50 |
|
| 51 |
-- |
| 52 |
Best regards, |
| 53 |
Michał Górny |
Archives