* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-13 21:58 Core Toolchain Infrastructure - Services for glibc Carlos O'Donell
@ 2023-07-14 11:38 ` Florian Weimer
2023-07-14 15:34 ` Konstantin Ryabitsev
2023-07-14 15:58 ` Mark Wielaard
2023-08-22 15:53 ` Frank Ch. Eigler
2 siblings, 1 reply; 14+ messages in thread
From: Florian Weimer @ 2023-07-14 11:38 UTC (permalink / raw)
To: Carlos O'Donell via Libc-alpha
Cc: Carlos O'Donell, Konstantin Ryabitsev, Joseph Myers,
Ryan S. Arnold, Paul Eggert, Jakub Jelinek, Maxim Kuvyrkov,
Andreas Schwab
* Carlos O'Donell via Libc-alpha:
> * Mailing lists
> * Support public-inbox for mailing list archives.
> * Use of public-inbox means archives can be cloned and copied.
> * Use of LF IT Subspace mailing list services (mlmmj, postfix).
I assume LF IT is able to run mailing lists without “via” From:
rewriting?
> * bug database
> * Consider starting fresh in new Bugzilla 5.0.4+ instance and freeze old product.
> * glibc component in sourceware instance marked "Not open for new bugs."
> * No easy way to clone this but we can discuss options.
> * Isolate bugzilla from other services.
Does LF IT offer some Bugzilla anti-spam services? To what extent do we
need to constrain new sign-ups?
We have one custom extension I know of: suppressing notifications when
setting security+ because it was deemed too noisy for old bugs. This
should not be necessary anymore; most of the bugs missing security+
analysis are current.
> * git
> * Migrate to gitolite
> * Community manages access via gitolite keys.
> * Minimize all access to sources and isolate from other processes.
> * Minimal server side web hooks where required.
> * Isolate git service from other services.
> * Stop supporting svn/cvs and provide tarball dumps.
Can we keep using the AdaCore hooks? Or would they have to run on the
side somehow? Who is going to implement changes to the AdaCore scripts?
> * wiki
> * Migrate to git-based documentation with existing content copied over.
> * Suggest rst/Sphinx or similar to existing discussions for GCC docs.
> * Sphinx with themes can provide a lot of flexibility for display.
> * Isolate wiki service from other services.
Will this be a separate Git repository, with different commit rules?
I do not particularly like the current MoinMoin wiki, but at least it
has a preview button. We'd lose that with a pure Git-based workflow.
> * Website
> * Provide a simple static site.
> * Isolate web hosting from other services.
How do we keep the online manual up-to-date?
> * Meeting
> * Already migrated away from proprietary solutions.
> * Continue to use LF IT BBB instance for glibc meetings including weekly patch review.
> * Isolate BBB from other services.
Ironically, with that move we lost support for open standards like SIP
dial-in. I assume there is no plan to bring that back, as the SIP
situation with BBB isn't great.
Thanks,
Florian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-14 11:38 ` Florian Weimer
@ 2023-07-14 15:34 ` Konstantin Ryabitsev
2023-07-18 11:47 ` Siddhesh Poyarekar
2023-08-03 10:10 ` Florian Weimer
0 siblings, 2 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2023-07-14 15:34 UTC (permalink / raw)
To: Florian Weimer
Cc: Carlos O'Donell via Libc-alpha, Carlos O'Donell,
Joseph Myers, Ryan S. Arnold, Paul Eggert, Jakub Jelinek,
Maxim Kuvyrkov, Andreas Schwab
On Fri, Jul 14, 2023 at 01:38:00PM +0200, Florian Weimer wrote:
> > * Support public-inbox for mailing list archives.
> > * Use of public-inbox means archives can be cloned and copied.
> > * Use of LF IT Subspace mailing list services (mlmmj, postfix).
>
> I assume LF IT is able to run mailing lists without “via” From:
> rewriting?
Yes, that practice is horrible and we do not support it in any way shape or
form for mailing lists.
> > * bug database
> > * Consider starting fresh in new Bugzilla 5.0.4+ instance and freeze old product.
> > * glibc component in sourceware instance marked "Not open for new bugs."
> > * No easy way to clone this but we can discuss options.
> > * Isolate bugzilla from other services.
>
> Does LF IT offer some Bugzilla anti-spam services? To what extent do we
> need to constrain new sign-ups?
We have various approaches here, depending on the project.
We do not constrain sign-ups for bugzilla.kernel.org. We have a script that
reports new comments containing links or potentially spammy attachments. These
comments are junked and accounts posting them are banned.
We do constrain sign-ups for bugzilla.yoctoproject.org -- users must request a
new account to be created before they can file any bugs.
> Can we keep using the AdaCore hooks? Or would they have to run on the
> side somehow? Who is going to implement changes to the AdaCore scripts?
This is the main point of contemplation -- we do not currently support custom
hooks on the server side:
- they tend to significantly slow down pushes
- they run extensive codebases with the same permissions as the owner of the
repositories, significantly increasing security risks
Our recommendation was to move all CI tasks to a system that is better suited
for it. For example, CI can run on a patchwork system and the pre-commit hook
can then check that each commit matches a patchwork entry that passed CI.
> > * wiki
> > * Migrate to git-based documentation with existing content copied over.
> > * Suggest rst/Sphinx or similar to existing discussions for GCC docs.
> > * Sphinx with themes can provide a lot of flexibility for display.
> > * Isolate wiki service from other services.
>
> Will this be a separate Git repository, with different commit rules?
>
> I do not particularly like the current MoinMoin wiki, but at least it
> has a preview button. We'd lose that with a pure Git-based workflow.
RTD documentation is written in ReST, for which there are many editors that
provide preview functionality.
-K
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-14 15:34 ` Konstantin Ryabitsev
@ 2023-07-18 11:47 ` Siddhesh Poyarekar
2023-07-18 12:26 ` Jakub Jelinek
2023-08-03 10:10 ` Florian Weimer
1 sibling, 1 reply; 14+ messages in thread
From: Siddhesh Poyarekar @ 2023-07-18 11:47 UTC (permalink / raw)
To: Konstantin Ryabitsev, Florian Weimer
Cc: Carlos O'Donell via Libc-alpha, Carlos O'Donell,
Joseph Myers, Ryan S. Arnold, Paul Eggert, Jakub Jelinek,
Maxim Kuvyrkov, Andreas Schwab
On 2023-07-14 11:34, Konstantin Ryabitsev via Libc-alpha wrote:
>> Can we keep using the AdaCore hooks? Or would they have to run on the
>> side somehow? Who is going to implement changes to the AdaCore scripts?
>
> This is the main point of contemplation -- we do not currently support custom
> hooks on the server side:
>
> - they tend to significantly slow down pushes
> - they run extensive codebases with the same permissions as the owner of the
> repositories, significantly increasing security risks
>
> Our recommendation was to move all CI tasks to a system that is better suited
> for it. For example, CI can run on a patchwork system and the pre-commit hook
> can then check that each commit matches a patchwork entry that passed CI.
This would mean porting AdaCore hooks to a patchwork trybot. This would
be an acceptable solution for glibc, but I'm not sure how useful this
would be on the whole since gcc doesn't use patchwork as extensively at
the moment. Also, we need to figure out who's going to do this.
Sid
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-18 11:47 ` Siddhesh Poyarekar
@ 2023-07-18 12:26 ` Jakub Jelinek
2023-07-18 13:19 ` Jeff Law
2023-07-18 13:38 ` Konstantin Ryabitsev
0 siblings, 2 replies; 14+ messages in thread
From: Jakub Jelinek @ 2023-07-18 12:26 UTC (permalink / raw)
To: Siddhesh Poyarekar
Cc: Konstantin Ryabitsev, Florian Weimer,
Carlos O'Donell via Libc-alpha, Carlos O'Donell,
Joseph Myers, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov,
Andreas Schwab
On Tue, Jul 18, 2023 at 07:47:37AM -0400, Siddhesh Poyarekar wrote:
> On 2023-07-14 11:34, Konstantin Ryabitsev via Libc-alpha wrote:
> > > Can we keep using the AdaCore hooks? Or would they have to run on the
> > > side somehow? Who is going to implement changes to the AdaCore scripts?
> >
> > This is the main point of contemplation -- we do not currently support custom
> > hooks on the server side:
> >
> > - they tend to significantly slow down pushes
> > - they run extensive codebases with the same permissions as the owner of the
> > repositories, significantly increasing security risks
> >
> > Our recommendation was to move all CI tasks to a system that is better suited
> > for it. For example, CI can run on a patchwork system and the pre-commit hook
> > can then check that each commit matches a patchwork entry that passed CI.
>
> This would mean porting AdaCore hooks to a patchwork trybot. This would be
> an acceptable solution for glibc, but I'm not sure how useful this would be
> on the whole since gcc doesn't use patchwork as extensively at the moment.
> Also, we need to figure out who's going to do this.
It is definitely not acceptable for gcc, we strongly rely on server side
pre-commit hooks for various different tasks.
Jakub
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-18 12:26 ` Jakub Jelinek
@ 2023-07-18 13:19 ` Jeff Law
2023-07-18 13:24 ` Siddhesh Poyarekar
2023-07-20 17:43 ` Joseph Myers
2023-07-18 13:38 ` Konstantin Ryabitsev
1 sibling, 2 replies; 14+ messages in thread
From: Jeff Law @ 2023-07-18 13:19 UTC (permalink / raw)
To: Jakub Jelinek, Siddhesh Poyarekar
Cc: Konstantin Ryabitsev, Florian Weimer,
Carlos O'Donell via Libc-alpha, Carlos O'Donell,
Joseph Myers, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov,
Andreas Schwab
On 7/18/23 06:26, Jakub Jelinek via Libc-alpha wrote:
> On Tue, Jul 18, 2023 at 07:47:37AM -0400, Siddhesh Poyarekar wrote:
>> On 2023-07-14 11:34, Konstantin Ryabitsev via Libc-alpha wrote:
>>>> Can we keep using the AdaCore hooks? Or would they have to run on the
>>>> side somehow? Who is going to implement changes to the AdaCore scripts?
>>>
>>> This is the main point of contemplation -- we do not currently support custom
>>> hooks on the server side:
>>>
>>> - they tend to significantly slow down pushes
>>> - they run extensive codebases with the same permissions as the owner of the
>>> repositories, significantly increasing security risks
>>>
>>> Our recommendation was to move all CI tasks to a system that is better suited
>>> for it. For example, CI can run on a patchwork system and the pre-commit hook
>>> can then check that each commit matches a patchwork entry that passed CI.
>>
>> This would mean porting AdaCore hooks to a patchwork trybot. This would be
>> an acceptable solution for glibc, but I'm not sure how useful this would be
>> on the whole since gcc doesn't use patchwork as extensively at the moment.
>> Also, we need to figure out who's going to do this.
>
> It is definitely not acceptable for gcc, we strongly rely on server side
> pre-commit hooks for various different tasks.
BUt the key (I think) is they're not trybot/CI style hooks. They're
doing things like wiring up commits to the lists/bugzilla, verifying
ChangeLog bits and the like.
I think the point is that any hooks need serious thought about what they
do and the attack surface they represent. So for example firing off
pre-commit CI, not advisable. Having a hook that queries another system
for the state of pre-commit CI may be reasonable.
I would think that verifying ChangeLog format might fall into the
reasonable space. Not sure about lists/bz integration hooks.
jeff
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-18 13:19 ` Jeff Law
@ 2023-07-18 13:24 ` Siddhesh Poyarekar
2023-07-20 17:43 ` Joseph Myers
1 sibling, 0 replies; 14+ messages in thread
From: Siddhesh Poyarekar @ 2023-07-18 13:24 UTC (permalink / raw)
To: Jeff Law, Jakub Jelinek
Cc: Konstantin Ryabitsev, Florian Weimer,
Carlos O'Donell via Libc-alpha, Carlos O'Donell,
Joseph Myers, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov,
Andreas Schwab
On 2023-07-18 09:19, Jeff Law wrote:
>
>
> On 7/18/23 06:26, Jakub Jelinek via Libc-alpha wrote:
>> On Tue, Jul 18, 2023 at 07:47:37AM -0400, Siddhesh Poyarekar wrote:
>>> On 2023-07-14 11:34, Konstantin Ryabitsev via Libc-alpha wrote:
>>>>> Can we keep using the AdaCore hooks? Or would they have to run on the
>>>>> side somehow? Who is going to implement changes to the AdaCore
>>>>> scripts?
>>>>
>>>> This is the main point of contemplation -- we do not currently
>>>> support custom
>>>> hooks on the server side:
>>>>
>>>> - they tend to significantly slow down pushes
>>>> - they run extensive codebases with the same permissions as the
>>>> owner of the
>>>> repositories, significantly increasing security risks
>>>>
>>>> Our recommendation was to move all CI tasks to a system that is
>>>> better suited
>>>> for it. For example, CI can run on a patchwork system and the
>>>> pre-commit hook
>>>> can then check that each commit matches a patchwork entry that
>>>> passed CI.
>>>
>>> This would mean porting AdaCore hooks to a patchwork trybot. This
>>> would be
>>> an acceptable solution for glibc, but I'm not sure how useful this
>>> would be
>>> on the whole since gcc doesn't use patchwork as extensively at the
>>> moment.
>>> Also, we need to figure out who's going to do this.
>>
>> It is definitely not acceptable for gcc, we strongly rely on server side
>> pre-commit hooks for various different tasks.
> BUt the key (I think) is they're not trybot/CI style hooks. They're
> doing things like wiring up commits to the lists/bugzilla, verifying
> ChangeLog bits and the like.
>
> I think the point is that any hooks need serious thought about what they
> do and the attack surface they represent. So for example firing off
> pre-commit CI, not advisable. Having a hook that queries another system
> for the state of pre-commit CI may be reasonable.
>
> I would think that verifying ChangeLog format might fall into the
> reasonable space. Not sure about lists/bz integration hooks.
Yeah, putting ChangeLog format verification into a patchwork bot won't
work anyway since patchwork ignores the git commit message when
identifying patches.
Sid
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-18 13:19 ` Jeff Law
2023-07-18 13:24 ` Siddhesh Poyarekar
@ 2023-07-20 17:43 ` Joseph Myers
1 sibling, 0 replies; 14+ messages in thread
From: Joseph Myers @ 2023-07-20 17:43 UTC (permalink / raw)
To: Jeff Law
Cc: Jakub Jelinek, Siddhesh Poyarekar, Konstantin Ryabitsev,
Florian Weimer, Carlos O'Donell via Libc-alpha,
Carlos O'Donell, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov,
Andreas Schwab
On Tue, 18 Jul 2023, Jeff Law via Libc-alpha wrote:
> BUt the key (I think) is they're not trybot/CI style hooks. They're doing
> things like wiring up commits to the lists/bugzilla, verifying ChangeLog bits
> and the like.
>
> I think the point is that any hooks need serious thought about what they do
> and the attack surface they represent. So for example firing off pre-commit
> CI, not advisable. Having a hook that queries another system for the state of
> pre-commit CI may be reasonable.
>
> I would think that verifying ChangeLog format might fall into the reasonable
> space. Not sure about lists/bz integration hooks.
Details of what the GCC hooks do / check are documented in the GCC service
enumeration.
https://lore.kernel.org/cti-tac/7e59d8db-7b26-1249-ad5c-67b7f3411e1@codesourcery.com/T/#u
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-18 12:26 ` Jakub Jelinek
2023-07-18 13:19 ` Jeff Law
@ 2023-07-18 13:38 ` Konstantin Ryabitsev
1 sibling, 0 replies; 14+ messages in thread
From: Konstantin Ryabitsev @ 2023-07-18 13:38 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Siddhesh Poyarekar, Florian Weimer,
Carlos O'Donell via Libc-alpha, Carlos O'Donell,
Joseph Myers, Ryan S. Arnold, Paul Eggert, Maxim Kuvyrkov,
Andreas Schwab
On Tue, Jul 18, 2023 at 02:26:44PM +0200, Jakub Jelinek wrote:
> > This would mean porting AdaCore hooks to a patchwork trybot. This would be
> > an acceptable solution for glibc, but I'm not sure how useful this would be
> > on the whole since gcc doesn't use patchwork as extensively at the moment.
> > Also, we need to figure out who's going to do this.
>
> It is definitely not acceptable for gcc, we strongly rely on server side
> pre-commit hooks for various different tasks.
I'm not saying "no hooks at all," but the general rule is:
- a hook can run checks on the contents of the commit message
- a hook can query external systems for validation results (with a reasonably
short timeout)
The core principle is that hooks should be fast and shouldn't have a large
attack surface, because hooks are running with full access to the underlying
repository. Any CI builds or other validations should run prior to the push
and visible to the committer before the push is attempted. I mention patchwork
because it's a system we use, but other options exist (e.g. gerrit, though
I wouldn't use it just for CI purposes).
Regards,
-K
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-14 15:34 ` Konstantin Ryabitsev
2023-07-18 11:47 ` Siddhesh Poyarekar
@ 2023-08-03 10:10 ` Florian Weimer
1 sibling, 0 replies; 14+ messages in thread
From: Florian Weimer @ 2023-08-03 10:10 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Carlos O'Donell via Libc-alpha, Carlos O'Donell,
Joseph Myers, Ryan S. Arnold, Paul Eggert, Jakub Jelinek,
Maxim Kuvyrkov, Andreas Schwab
* Konstantin Ryabitsev:
> On Fri, Jul 14, 2023 at 01:38:00PM +0200, Florian Weimer wrote:
>> > * Support public-inbox for mailing list archives.
>> > * Use of public-inbox means archives can be cloned and copied.
>> > * Use of LF IT Subspace mailing list services (mlmmj, postfix).
>>
>> I assume LF IT is able to run mailing lists without “via” From:
>> rewriting?
>
> Yes, that practice is horrible and we do not support it in any way shape or
> form for mailing lists.
That's good to know.
>> > * bug database
>> > * Consider starting fresh in new Bugzilla 5.0.4+ instance and freeze old product.
>> > * glibc component in sourceware instance marked "Not open for new bugs."
>> > * No easy way to clone this but we can discuss options.
>> > * Isolate bugzilla from other services.
>>
>> Does LF IT offer some Bugzilla anti-spam services? To what extent do we
>> need to constrain new sign-ups?
>
> We have various approaches here, depending on the project.
>
> We do not constrain sign-ups for bugzilla.kernel.org. We have a script
> that reports new comments containing links or potentially spammy
> attachments. These comments are junked and accounts posting them are
> banned.
>
> We do constrain sign-ups for bugzilla.yoctoproject.org -- users must
> request a new account to be created before they can file any bugs.
Okay, so there are options, good.
>> Can we keep using the AdaCore hooks? Or would they have to run on the
>> side somehow? Who is going to implement changes to the AdaCore scripts?
>
> This is the main point of contemplation -- we do not currently support custom
> hooks on the server side:
>
> - they tend to significantly slow down pushes
> - they run extensive codebases with the same permissions as the owner of the
> repositories, significantly increasing security risks
>
> Our recommendation was to move all CI tasks to a system that is better
> suited for it. For example, CI can run on a patchwork system and the
> pre-commit hook can then check that each commit matches a patchwork
> entry that passed CI.
One way to deal with this on our end would be a policy that allows
branch rebases to pull faulty commits for a time. Lately we have pushed
some misformatted commit messages in the current setup, with its commit
hooks.
Thanks,
Florian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-13 21:58 Core Toolchain Infrastructure - Services for glibc Carlos O'Donell
2023-07-14 11:38 ` Florian Weimer
@ 2023-07-14 15:58 ` Mark Wielaard
2023-08-22 15:53 ` Frank Ch. Eigler
2 siblings, 0 replies; 14+ messages in thread
From: Mark Wielaard @ 2023-07-14 15:58 UTC (permalink / raw)
To: libc-alpha
Cc: Konstantin Ryabitsev, Joseph Myers, Ryan S. Arnold, Paul Eggert,
Jakub Jelinek, Maxim Kuvyrkov, Andreas Schwab
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
Hi Carlos,
On Thu, 2023-07-13 at 17:58 -0400, Carlos O'Donell via Libc-alpha
wrote:
> As part of this effort the Technical Advisory Committee (TAC) has
> evaluated the services used by glibc and how they could be migrated
> and serviced by the CTI project.
>
> The CTI TAC recommendation is to use Linux Foundation IT services
> for core infrastructure. The LF IT team already supports many of
> the same services for the Linux kernel and at scale. The migration
> would involve moving services from Sourceware.org to LF IT servers.
> We continue to be thankful and appreciative of the time spent by
> Sourceware.org volunteers in support of the current services.
Your goals seem to align with those of Sourceware and the expanded
services we have been setting up over the last couple of years
together. So hopefully you don't have to leave the community.
https://sourceware.org/mission.html
A couple of months ago we finalized the incorporation of Sourceware as
a Software Freedom Conservancy member project with eight community
members serving as Project Leadership Committee:
https://sfconservancy.org/news/2023/may/15/sourceware-joins-sfc/
If the community needs any help with any of the Sourceware services
please join one of the Open Office talks (there is one today, at 18:00
UTC, in #overseers on irc.libera.chat) or contact us through the
overseers mailinglist, bugzilla, etc at any time. See attached.
Cheers,
Mark
[-- Attachment #2: Attached message - Sourceware Open Office, Friday July 14, 18:00 UTC --]
[-- Type: message/rfc822, Size: 6201 bytes --]
From: Mark Wielaard via Overseers <overseers@sourceware.org>
To: overseers@sourceware.org
Cc: Mark Wielaard <mark@klomp.org>
Subject: Sourceware Open Office, Friday July 14, 18:00 UTC
Date: Fri, 14 Jul 2023 02:11:34 +0200
Message-ID: <20230714001134.GA29669@gnu.wildebeest.org>
Every second Friday of the month is the Sourceware Overseers Open
Office hour in #overseers on irc.libera.chat from 18:00 till 19:00
UTC. That is this Friday July 14th.
Please feel free to drop by with any Sourceware hosting questions.
Help with email (archives, spam), secure supply chain, setting up new
buildbot CI, producing snapshots, helping write up some POCs,
discussing extending services, what the Software Freedom Sourceware
Project Leadership Committee should prioritize, or just to say things
are all working fine.
Of course you are welcome to drop into the #overseers channel at any
time and we can also be reached through email and bugzilla:
https://sourceware.org/mission.html#organization
If you aren't already and want to keep up to date on Sourceware
infrastructure services then please also subscribe to the overseers
mailinglist. https://sourceware.org/mailman/listinfo/overseers
We are also on the fediverse these days:
https://fosstodon.org/@sourceware
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-07-13 21:58 Core Toolchain Infrastructure - Services for glibc Carlos O'Donell
2023-07-14 11:38 ` Florian Weimer
2023-07-14 15:58 ` Mark Wielaard
@ 2023-08-22 15:53 ` Frank Ch. Eigler
2023-08-23 7:57 ` Sourceware Infrastructure " Mark Wielaard
2023-08-29 20:45 ` Core Toolchain Infrastructure - " Carlos O'Donell
2 siblings, 2 replies; 14+ messages in thread
From: Frank Ch. Eigler @ 2023-08-22 15:53 UTC (permalink / raw)
To: Carlos O'Donell
Cc: libc-alpha, Konstantin Ryabitsev, Joseph Myers, Ryan S. Arnold,
Paul Eggert, Jakub Jelinek, Maxim Kuvyrkov, Andreas Schwab
> [...] Appended to this message are [...] an enumeration of the
> current services. [...]
Existing sourceware services for glibc also includes:
- the buildbot server, having run some 12,000 glibc builds since
inception: https://builder.sourceware.org/buildbot/#/builders
- the bunsen instance accumulating glibc testsuite results, presently
holding some 5,700 of them:
https://builder.sourceware.org/testruns/?has_keyvalue_k=testrun.git_describe&has_keyvalue_op=glob&has_keyvalue_v=*glibc*&has_keyvalue2_k=source.gitdescribe&has_keyvalue2_op=glob&has_keyvalue2_v=*&order_by=testrun.authored.time&order=desc&limit=10000&offset=0&offset=0
- the recently added 'snapshots' worker & server:
https://snapshots.sourceware.org/glibc/trunk/
- FChE
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Sourceware Infrastructure Services for glibc
2023-08-22 15:53 ` Frank Ch. Eigler
@ 2023-08-23 7:57 ` Mark Wielaard
2023-08-29 20:45 ` Core Toolchain Infrastructure - " Carlos O'Donell
1 sibling, 0 replies; 14+ messages in thread
From: Mark Wielaard @ 2023-08-23 7:57 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: libc-alpha, Konstantin Ryabitsev, Joseph Myers, Ryan S. Arnold,
Paul Eggert, Jakub Jelinek, Maxim Kuvyrkov, Andreas Schwab,
Alexandre Oliva
Hi Frank,
On Tue, Aug 22, 2023 at 11:53:43AM -0400, Frank Ch. Eigler via Libc-alpha wrote:
>
> > [...] Appended to this message are [...] an enumeration of the
> > current services. [...]
>
> Existing sourceware services for glibc also includes:
>
> - the buildbot server, having run some 12,000 glibc builds since
> inception: https://builder.sourceware.org/buildbot/#/builders
>
> - the bunsen instance accumulating glibc testsuite results, presently
> holding some 5,700 of them:
> https://builder.sourceware.org/testruns/?has_keyvalue_k=testrun.git_describe&has_keyvalue_op=glob&has_keyvalue_v=*glibc*&has_keyvalue2_k=source.gitdescribe&has_keyvalue2_op=glob&has_keyvalue2_v=*&order_by=testrun.authored.time&order=desc&limit=10000&offset=0&offset=0
>
> - the recently added 'snapshots' worker & server:
> https://snapshots.sourceware.org/glibc/trunk/
Thanks for the list. Note that Sourceware Infrastructure Services are
also listed per project at https://sourceware.org/projects.html
For glibc it is currently missing bunsen (would be nice to have short
URLs per project btw) and the fsf-tech team provided services for GNU
projects. Which should probably be added. There is also a generic
services list at https://sourceware.org/mission.html#services
Also note that over the last couple of years we setup a real
Sourceware organization to make sure the Sourceware community can be
sustained for another 25 years:
https://sourceware.org/sourceware-25-roadmap.html
So if there are any services missing or could be improved, please do
reach out to overseers@, file infrastructure bugs or come talk at one
of the open office hours on irc (or really at any time). See
https://sourceware.org/mission.html#organization
Cheers,
Mark
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Core Toolchain Infrastructure - Services for glibc
2023-08-22 15:53 ` Frank Ch. Eigler
2023-08-23 7:57 ` Sourceware Infrastructure " Mark Wielaard
@ 2023-08-29 20:45 ` Carlos O'Donell
1 sibling, 0 replies; 14+ messages in thread
From: Carlos O'Donell @ 2023-08-29 20:45 UTC (permalink / raw)
To: Frank Ch. Eigler
Cc: libc-alpha, Konstantin Ryabitsev, Joseph Myers, Ryan S. Arnold,
Paul Eggert, Jakub Jelinek, Maxim Kuvyrkov, Andreas Schwab
On 8/22/23 11:53, Frank Ch. Eigler wrote:
>
>> [...] Appended to this message are [...] an enumeration of the
>> current services. [...]
>
> Existing sourceware services for glibc also includes:
Thanks, I've noted the additional services provided for sourceware projects.
> - the buildbot server, having run some 12,000 glibc builds since
> inception: https://builder.sourceware.org/buildbot/#/builders
> - the bunsen instance accumulating glibc testsuite results, presently
> holding some 5,700 of them:
> https://builder.sourceware.org/testruns/?has_keyvalue_k=testrun.git_describe&has_keyvalue_op=glob&has_keyvalue_v=*glibc*&has_keyvalue2_k=source.gitdescribe&has_keyvalue2_op=glob&has_keyvalue2_v=*&order_by=testrun.authored.time&order=desc&limit=10000&offset=0&offset=0
> - the recently added 'snapshots' worker & server:
> https://snapshots.sourceware.org/glibc/trunk/
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 14+ messages in thread