Re: Proposed changes to the commit policy (#59513)

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi,

On Mon, 30 Jan 2023 at 22:03, Christopher Baines <mail@cbaines.net> wrote:

> In the past and currently to some extent, it's been possible to move
> very quickly without comprimising on quality. However, my feeling on
> this is that if we want to have quality support for non x86_64-linux
> architectures, reproducible builds, packages that build reliably,
> ... then that's going to require more effort. That might mean some
> changes happen more slowly, but this is why I'm working on the tools and
> processes, as I think that's a path to trying to maintain and improve
> the quality while reducing the impact to pace and enjoyment.

I agree.

For what it is worth, this kind of slow transition seems common to many
projects. :-) For example, a recent story about Yocto [1].  Teaser:

        Our scale also means patch requirements are more demanding
        now. Once, when the number of people using the project was
        small, the impact of breaking things was also more limited,
        allowing a little more freedom in development. Now, if we accept
        a change commit and something breaks, it becomes an instant
        emergency, […]

Well, happy to discuss in Brussels or elsewhere such topic: being more
reliable with fun. :-)

Cheers,
simon


(From LWN [2] ;-))

1: <https://www.linux.com/audience/maintainer-confidential-opportunities-and-challenges-of-the-ubiquitous-but-under-resourced-yocto-project/>
2: <https://lwn.net/Articles/921646/>