guix-patches
[Top][All Lists]
Advanced

[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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]