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

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2259 bytes --]


Andreas Enge <andreas@enge.fr> writes:

> Am Wed, Jan 18, 2023 at 11:45:20AM +0000 schrieb Christopher Baines:
>> > as a quick concrete question: Do simple package updates still count as
>> > trivial, or do they need to go through the patches mailing list?
>> My feeling on this is that "simple" package updates are often not
>> trivial, or at least doing rigorous testing for these updates isn't
>> trivial. A definition of trivial might be "having little value or
>> importance", and I don't think that's generally the case for version
>> updates, they're often a valuable and important change.
>
> So I tried it once, and find the hassle offputting. It feels like doubling
> the effort - after doing the real work, I need to get back to it a week
> later and more or less go through the motions again (rebase the commit
> and resign it, recompile Guix, build the package again just in case),
> plus the debbugs effort.
>
> So expect even less package updates from my part in the future... These
> were the kind of instant gratification actions one could do more or less
> in the background, and they have become more complex administrative
> endeavours with delayed gratification. (I also do not know how to set up
> git-sendmail with my remote SMTP server login and password, but this is
> a one-time cost of learning which does not matter that much.)

I appreciate feeling put off by this, although I'd maybe reframe it as
balancing quality with other factors, and how that's going to change for
Guix as a project over time.

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'm sure there are ways of addressing at least some of the problems you
mention above, so it's really valuable to mention them so that we can
work towards solutions.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]