Re: Best method to share that something is broken + patches?

Florian Weimer <[email protected]> Tue, 22 Nov 2022 13:08:48 +0100
Newsgroups dev.linux.lists.c-std-porting
Message-ID <[email protected]>
* 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