Re: Action: Setup working group for the GNU Toolchain proposal to migrate to LF IT managed services
Joel Brobecker <[email protected]> Mon, 21 Nov 2022 07:31:13 +0400
| Newsgroups | org.linuxfoundation.lists.cti-tac |
|---|---|
| Message-ID | <Y3rxAYa/oc5s/R/[email protected]> |
> Details:
>
> - Working group will enumerate in detail the GNU Toolchain project services
> for the projects including gcc, glibc, binutils and gdb.
Here is what Simon and I could think of for GDB:
* Git Repository
* Web-based navigation of the Git repository
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git
* git-hooks
* Website
- Handwritten pages (in a CVS (!) repository)
- scripts generating website contents (doc, ARI, etc)
* [methodology can be rediscussed, but for now, we have the following
workflow]
SSH access to the machine hosting the website, as the scripts above
generating website contents are run by the release manager, after
having ssh'ed onto sourceware.org.
* Wiki
* bug tracker (bugzilla)
* Not sure if we want to change this or not, but sourceware.org
also offers FTP download of releases, pre-releases, and snapshots.
Releases are made available on ftp.gnu.org as well, and I do not
think we want to change that part.
* Some scripts spawned from the git-hooks, due to the binutils-gdb's
git-hooks config:
- /[...]/binutils-gdb.git/hooks-bin/commit-extra-checker.py
Verifies that we do not have this issue:
# With commits created using "git am" of patches sent via the gdb@ or
# gdb-patches@ mailing list, it's possible that the author information
# gets changed into "xxx via [email protected]". Catch and reject those,
# so the person doing the push can fix this before the push is allowed.
- /sourceware/infra/bin/email-to-bugzilla
Sends a copy of commit messages to bugzilla if commit
has a PR number in it.
- /git/binutils-gdb.git/hooks-bin/post-receive
Calls the irker (IRC notification of new commits)
We'll need a way to get those installed on the machine hosting
the git repository, and hopefully also a convenient way for us
to allow testing before deployment (right now, we SSH to
sourceware.org).
* patchwork
(https://patchwork.sourceware.org/project/gdb/list/)
Simon reports that this instance doesn't get much use at the moment,
because it gets filled so quickly and is impossible to keep up to date.
I (Joel) think that the project really needs to have a proper
review system. It's too time-consuming and ineffective to have each
maintainer do its own tracking. So having a review system that GDB
Maintaniers are willing to adopt is very important, IMO. Maybe
patchwork can fit the bill, or maybe it might be another system.
Something for Simon and I perhaps to discuss with the other GDB
maintainers?
--
Joel