c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Best method to share that something is broken + patches?
@ 2022-11-22  7:48 Sam James
  2022-11-22  7:55 ` Sam James
  2022-11-22 12:08 ` Florian Weimer
  0 siblings, 2 replies; 3+ messages in thread
From: Sam James @ 2022-11-22  7:48 UTC (permalink / raw)
  To: c-std-porting

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

Hi all,

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.

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.

2. How do we share patches for them?

3. How do we minimise noise while doing 1. and 2.?

I'm thinking maybe a shared git repository for the patches (and/or just
links to bug
reports), while we keep the list for discussion of non-trivial issues,
or significant
PSAs (including a major package being broken, especially if it doesn't
get frequent
releases) rather than polluting the ML with some random package which
only a single
distro happens to maintain.

(Of course, we won't be that strict with the rules, so if someone is
unsure or wants help, they're
free to ask on the ML, I just don't want to flood it with a bunch of
obvious patches.)

Thoughts?

Best,
sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Best method to share that something is broken + patches?
  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
  1 sibling, 0 replies; 3+ messages in thread
From: Sam James @ 2022-11-22  7:55 UTC (permalink / raw)
  To: c-std-porting

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]


Sam James <sam@gentoo.org> writes:

> [[PGP Signed Part:Undecided]]
>
> 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.
>
> [...]
>
> I'm thinking maybe a shared git repository for the patches (and/or just
> links to bug
> reports), while we keep the list for discussion of non-trivial issues,
> or significant
> PSAs (including a major package being broken, especially if it doesn't
> get frequent
> releases) rather than polluting the ML with some random package which
> only a single
> distro happens to maintain.

We may also need some weak guidelines on package name normalisation
and suggestions welcome for the structure of any repo if we pursue
that option.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Best method to share that something is broken + patches?
  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
  1 sibling, 0 replies; 3+ messages in thread
From: Florian Weimer @ 2022-11-22 12:08 UTC (permalink / raw)
  To: Sam James; +Cc: c-std-porting

* 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-11-22 12:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).