Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.
Carlos O'Donell <[email protected]> Wed, 24 May 2023 15:58:06 -0400
| Newsgroups | org.linuxfoundation.lists.cti-tac |
|---|---|
| Organization | Red Hat |
| Message-ID | <[email protected]> |
On 5/24/23 14:44, Joseph Myers wrote: > On Wed, 24 May 2023, Siddhesh Poyarekar wrote: > >> There's probably a viable middle ground here for glibc, where commits that >> don't have an entry in patchwork get sent to the list. Given the current >> traffic for libc-alpha, it won't add much overhead to libc-alpha and also meet >> auditing requirements. > > I think this is overly complicating things. (Though it would be good for > glibc to have the check done for GCC that once a commit is in the > repository, emails aren't sent out again for a merge of that commit into a > user / vendor / development branch.) > >> For the release/* branches, it probably makes more sense to send the commits >> to libc-stable, thus removing the need for developers to send [committed X.Y] >> to the list. This should then limit the utility of glibc-cvs to private >> branch pushes. I doubt if anybody cares about pushes to private branches, do >> they? > > I think commits to user / vendor branches can be of interest. They may > suggest things that would be worth adding to master (even if the original > author didn't think of them as appropriate for master, or loses interest > in them), for example. And in fact this is how I track Google's public work on the GRTE glibc branches. -- Cheers, Carlos.