From: Carlos O'Donell <carlos@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>,
Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
cti-tac@lists.linuxfoundation.org
Subject: Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.
Date: Wed, 24 May 2023 15:58:06 -0400 [thread overview]
Message-ID: <ed594f9e-92ee-439d-ba76-ce4e2abbcfd3@redhat.com> (raw)
In-Reply-To: <d1a3b6ca-0a3-374a-9a52-e2839b9b6f1@codesourcery.com>
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.
next prev parent reply other threads:[~2023-05-24 19:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-19 22:47 Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration Joseph Myers
2023-05-22 10:11 ` Joel Brobecker
2023-05-24 12:44 ` Carlos O'Donell
2023-05-24 13:43 ` Siddhesh Poyarekar
2023-05-24 14:12 ` Carlos O'Donell
2023-05-24 15:18 ` Siddhesh Poyarekar
2023-05-23 17:38 ` Konstantin Ryabitsev
2023-05-23 19:34 ` Joseph Myers
2023-05-23 19:52 ` Konstantin Ryabitsev
2023-05-23 20:12 ` Joseph Myers
2023-05-23 20:21 ` Konstantin Ryabitsev
2023-05-23 22:12 ` Joseph Myers
2023-05-24 16:29 ` Konstantin Ryabitsev
2023-05-24 18:13 ` Siddhesh Poyarekar
2023-05-24 18:55 ` Brian Behlendorf
2023-05-24 21:27 ` Siddhesh Poyarekar
2023-05-25 11:06 ` Carlos O'Donell
2023-05-24 19:06 ` Konstantin Ryabitsev
2023-05-24 19:42 ` Joseph Myers
2023-05-24 21:12 ` Siddhesh Poyarekar
2023-05-25 11:12 ` Carlos O'Donell
2023-05-24 18:58 ` Joseph Myers
2023-05-24 12:11 ` Siddhesh Poyarekar
2023-05-24 18:44 ` Joseph Myers
2023-05-24 19:58 ` Carlos O'Donell [this message]
2023-05-24 12:57 ` Carlos O'Donell
2023-05-24 18:46 ` Joseph Myers
2023-05-24 20:19 ` Carlos O'Donell
2023-05-24 20:48 ` Joseph Myers
-- strict thread matches above, loose matches on Subject: below --
2023-04-03 17:24 Carlos O'Donell
2023-04-12 20:46 ` Konstantin Ryabitsev
2023-04-12 21:28 ` Brian Behlendorf
2023-05-19 21:00 ` Konstantin Ryabitsev
2023-05-22 14:37 ` Ian Kelling
2023-05-24 20:50 ` Carlos O'Donell
2023-05-24 21:53 ` Ian Kelling
2023-05-25 11:02 ` Carlos O'Donell
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=ed594f9e-92ee-439d-ba76-ce4e2abbcfd3@redhat.com \
--to=carlos@redhat.com \
--cc=cti-tac@lists.linuxfoundation.org \
--cc=joseph@codesourcery.com \
--cc=konstantin@linuxfoundation.org \
--cc=siddhesh@gotplt.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.