c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Sam James <sam@gentoo.org>
Cc: c-std-porting@lists.linux.dev
Subject: Re: Best method to share that something is broken + patches?
Date: Tue, 22 Nov 2022 13:08:48 +0100	[thread overview]
Message-ID: <87h6yrqjhr.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <87zgcjfmyi.fsf@gentoo.org> (Sam James's message of "Tue, 22 Nov 2022 07:48:53 +0000")

* Sam James:

> We didn't really have a proper chance to discuss how the list
> mechanics should work yet, as we got caught a bit off guard by the LWN
> (and then Phoronix) articles.

Yeah, that's true.

> For me, there's a few big questions:
> 1. How do we notify others that a package is broken? I feel like we
> shouldn't bother if something has very frequent releases, but
> otherwise, it's probably going to be worth sharing.

I'm keeping track of fixes here:

  <https://gitlab.com/fweimer-rh/fedora-modernc>

I could configure the repository so that updates to it are posted to
this list.  But it's pretty noisy.  And I'm not sure if other Fedora
maintainers will contribute patches there.

> 2. How do we share patches for them?

For Fedora, applying a patch and verifying it is typically more work
than creating it.  The patch creation process itself is fairly simple
compared to the administrative overhead.  In my experience so far, the
best way to find upstream patches is to fix the build, and then look for
recent upstream changes to these files.  So I'm not sure how helpful
sharing will be.

I think our best bet for sharing is to do it via upstream.  If there
isn't an upstream left, that's okay, too, because people *not* using
distributions will not be impacted by the build being broken.  The most
significant gap seem to be upstreams which are still around, but do not
follow an open development process (or do not take our patches for other
reasons).  In those cases, it's hard to make the patches stick.

I think Gentoo has been at this for a bit longer.  Looking back at the
patches you created, are they actually share-worthy?

Thanks,
Florian


      parent reply	other threads:[~2022-11-22 12:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22  7:48 Best method to share that something is broken + patches? Sam James
2022-11-22  7:55 ` Sam James
2022-11-22 12:08 ` Florian Weimer [this message]

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

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

  git send-email \
    --in-reply-to=87h6yrqjhr.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=c-std-porting@lists.linux.dev \
    --cc=sam@gentoo.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.
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 NNTP newsgroup(s).