[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#59513] [PATCH] doc: contributing: Tweak the Commit Policy.
From: |
Ludovic Courtès |
Subject: |
[bug#59513] [PATCH] doc: contributing: Tweak the Commit Policy. |
Date: |
Fri, 02 Dec 2022 10:45:04 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi,
Christopher Baines <mail@cbaines.net> skribis:
>> I would write:
>>
>> … changes), and if you're confident (which means you
>> successfully built it in a chroot setup, and have done a
>> reasonable copyright and license auditing), it’s OK to commit.
>
> chroot setup doesn't really make sense to me, I'm not sure why that
> needs specifying
The chroot requirement is specified because a non-isolated build is
worth nothing: it might work on some machine and fail on another one for
hard-to-find reasons.
We could stop mentioning it if we think everyone keeps chroot enabled
(that’s probably the case), but it doesn’t hurt to keep it.
> (like do we not want things for the Hurd pushing, since the
> guix-daemon doesn't support build isolation there yet)?
Well yes, that’s the thing. For i586-gnu we’re currently stuck because
we haven’t yet defined how to normalize the build environment:
https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/
https://issues.guix.gnu.org/43857
And it’s not theoretical: some util-linux tests may or may not work
depending on whether the Hurd box has /proc set up, the Texinfo test
suite would pass if there happens to be a usable ‘pt_chown’ program
around (see <https://issues.guix.gnu.org/59616>), etc.
So I think the current situation is that we can build base packages for
i586-gnu, that’s fine, but don’t have a solid foundation like we do on
GNU/Linux, so there’s no point in going too far.
Now, I don’t think the i586-gnu situation is an important consideration
for the commit policy.
Ludo’.