unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.)
Date: Thu, 05 Jul 2018 11:01:19 +0200	[thread overview]
Message-ID: <87d0w2f44g.fsf@gnu.org> (raw)
In-Reply-To: <871scin5bs.fsf_-_@netris.org> (Mark H. Weaver's message of "Wed, 04 Jul 2018 15:55:51 -0400")

Hi again Mark,

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> The end result is that the wishes of the x86_64-using majority are the
>>> only ones that seem to matter in this community, and other users are
>>> frequently left in a bad spot.  This makes it increasingly unlikely that
>>> we'll ever gain a significant number of non-x86_64 users.
>>
>> This kind of rant is really unhelpful.  You’re shouting at someone who
>> *is* doing the work of keeping things running.
>
> I wasn't actually shouting, but in retrospect I can see how it came off
> that way.  I apologize for any hurt feelings that I caused.

I think the error is to suggest that people genuinely don’t care about
the issues.

Often they’re unaware, and sometimes they make suboptimal tradeoffs, as
in the PatchELF case, simply because the status quo is worse than the
suboptimal tradeoff.

> However, I do feel frustrated by the fact that it's considered
> acceptable in this community to leave non-x86_64 users with broken
> systems in the name of "moving things forward" for x86_64 users.

Like I write, it’s not “considered acceptable.”  That’s just not the way
it works.

There’s an implicit rule that we should not break any architecture
badly, but just like sometimes packages fail to build, sometimes there
are architecture-specific issues; and just like an unpopular package
that fails to build is likely to remain that way, an unpopular
architecture is more likely to have issues.

We don’t have to take it as a fact of life, though.  We can work
proactively to mitigate that, and support for those architectures in the
build farm, along with heads-up from overseers (like you’ve been doing
to great effect!) can greatly help.  It won’t bring, say, MIPS to the
level of support of x86_64, but it can reduce damage.

> I'm open to suggestions.  Do you see any solution to the problem of how
> to attract more non-x86_64 users, given our current policies?

Efraim, Danny, Vagrant, Julien, Mathieu, etc. have done a lot of work
fiddling with ARMv7 and AArch64.  We should encourage that, and
providing timely substitutes for the arches is one way to do it, and
ultimately to attract more users and contributors.

Thanks,
Ludo’.

  parent reply	other threads:[~2018-07-05  9:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180702101757.22792.51026@vcs0.savannah.gnu.org>
     [not found] ` <20180702101758.97A6020543@vcs0.savannah.gnu.org>
2018-07-02 17:29   ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Mark H Weaver
2018-07-02 18:06     ` Marius Bakke
2018-07-03 19:20       ` Mark H Weaver
2018-07-04  7:21         ` Ludovic Courtès
2018-07-04 19:55           ` RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.) Mark H Weaver
2018-07-04 22:32             ` Kei Kebreau
2018-07-05  8:39               ` Ludovic Courtès
2018-07-05 14:15                 ` Kei Kebreau
2018-07-05  9:04               ` Jonathan Brielmaier
2018-07-05 19:40                 ` Andreas Enge
2018-07-05  6:38             ` Ricardo Wurmus
2018-07-05  8:46               ` Ludovic Courtès
2018-07-05  9:52               ` Andreas Enge
2018-07-05  8:50             ` Ludovic Courtès
2018-07-05  9:01             ` Ludovic Courtès [this message]
2018-07-02 18:28     ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Marius Bakke
2018-07-03 19:24       ` Mark H Weaver
2018-07-04  7:27         ` Ludovic Courtès
2018-07-04 14:27           ` Marius Bakke
2018-07-03 21:28       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d0w2f44g.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=mhw@netris.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).