| Message ID | 20240523143752.385810-1-jwakely@redhat.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | main: Use inbox.sourceware.org for repos hosted there | expand |
Hi, On Thu, 2024-05-23 at 15:30 +0100, Jonathan Wakely wrote: > Like the kernel, the GNU toolchain projects hosted on sourceware.org all > use email-based patch submission/review processes, and a number of > people are using b4 with inbox.sourceware.org now. This streamlines > things for those people. > > I don't know if this patch would be acceptable for b4. It's obviously > very specific to sourceware projects, but then the existing default is > very specific to the kernel! :) Thanks! I would really appreciate this this could be accepted. It would be really convenient, not just for the four GNU toolchain projects hosted at sourceware but also the other 20+ core toolchain and developer tools (annobin, bzip2, elfutils, libabigail, newlib, systemtap, valgrind, ...) https://sourceware.org/projects.html > Of course this wouldn't scale if every public-inbox installation wanted > to hack b4 to work for their case too, but maybe GCC, Glibc etc. are > significant enough to deserve this special case. This is probably overdesign, but maybe we can implement a standerd DNS (c)name for a git domains providing a public-inbox instance? So you could lookup if public-inbox.<git-origin-url> exists? Cheers, Mark
On Thu, May 23, 2024 at 03:30:16PM GMT, Jonathan Wakely wrote: > Like the kernel, the GNU toolchain projects hosted on sourceware.org all > use email-based patch submission/review processes, and a number of > people are using b4 with inbox.sourceware.org now. This streamlines > things for those people. > > I don't know if this patch would be acceptable for b4. It's obviously > very specific to sourceware projects, but then the existing default is > very specific to the kernel! :) I understand the reason for this, but I'd much rather this was set in .b4-config, as it would obviously scale much better than hardcoding more and more projects into the source. Especially if origin URLs happen to change in the future. Have you considered submitting a change that includes a .b4-config into the repos? -K
On Thu, 23 May 2024 at 16:16, Konstantin Ryabitsev wrote: > > On Thu, May 23, 2024 at 03:30:16PM GMT, Jonathan Wakely wrote: > > Like the kernel, the GNU toolchain projects hosted on sourceware.org all > > use email-based patch submission/review processes, and a number of > > people are using b4 with inbox.sourceware.org now. This streamlines > > things for those people. > > > > I don't know if this patch would be acceptable for b4. It's obviously > > very specific to sourceware projects, but then the existing default is > > very specific to the kernel! :) > > I understand the reason for this, but I'd much rather this was set in > .b4-config, as it would obviously scale much better than hardcoding more > and more projects into the source. Especially if origin URLs happen to > change in the future. > > Have you considered submitting a change that includes a .b4-config into > the repos? I have now, at least for GCC: https://inbox.sourceware.org/20240523155116.390918-1-jwakely@redhat.com Thanks for considering the patch anyway.
On Thu, May 23, 2024 at 04:56:01PM GMT, Jonathan Wakely wrote: > > > I don't know if this patch would be acceptable for b4. It's obviously > > > very specific to sourceware projects, but then the existing default is > > > very specific to the kernel! :) > > > > I understand the reason for this, but I'd much rather this was set in > > .b4-config, as it would obviously scale much better than hardcoding more > > and more projects into the source. Especially if origin URLs happen to > > change in the future. > > > > Have you considered submitting a change that includes a .b4-config into > > the repos? > > I have now, at least for GCC: > https://inbox.sourceware.org/20240523155116.390918-1-jwakely@redhat.com Great. You should also consider including: send-series-to = gcc-patches@gcc.gnu.org This would make it easy to use b4 prep to submit patches to gcc. -K
diff --git a/src/b4/__init__.py b/src/b4/__init__.py index fea7498..2b20ad6 100644 --- a/src/b4/__init__.py +++ b/src/b4/__init__.py @@ -2861,6 +2861,18 @@ def _setup_main_config(cmdargs: Optional[argparse.Namespace] = None) -> None: global MAIN_CONFIG defcfg = copy.deepcopy(DEFAULT_CONFIG) + + # If origin is a repo hosted on sourceware.org then use its public-inbox + # as the default instead of lore.kernel.org. This will be overridden by + # any explicit setting in .b4-config or the git config. + originurl = get_config_from_git(r'remote.origin').get('url') + if originurl is not None: + if "//gcc.gnu.org/git/" in originurl or "//sourceware.org/git/" in originurl: + logger.debug('Using inbox.sourceware.org as default host') + defcfg['midmask'] = 'https://inbox.sourceware.org/%s' + defcfg['linkmask'] = 'https://inbox.sourceware.org/%s' + + # some options can be provided via the toplevel .b4-config file, # so load them up and use as defaults topdir = git_get_toplevel()
Like the kernel, the GNU toolchain projects hosted on sourceware.org all use email-based patch submission/review processes, and a number of people are using b4 with inbox.sourceware.org now. This streamlines things for those people. I don't know if this patch would be acceptable for b4. It's obviously very specific to sourceware projects, but then the existing default is very specific to the kernel! :) Of course this wouldn't scale if every public-inbox installation wanted to hack b4 to work for their case too, but maybe GCC, Glibc etc. are significant enough to deserve this special case. -- >8 -- This adjusts the default config to use inbox.sourceware.org instead of lore.kernel.org if the git repo's 'origin' remote is hosted on sourceware.org (e.g., GCC, Glibc, etc.) This avoids needing to override the b4.midmask and b4.linkmask config for every sourceware-hosted repo, which helps people who contribute to both the kernel and toolchain projects (so don't want to override b4.midmask globally). An explicit midmask or linkmask setting in .b4-config or git config will still override this default. The change only works if the remote 'origin' exists in the repo, and assumes that if it does then it's meaningful, so somebody hasn't configured remote.origin to point to sourceware in a repo that isn't actually hosted there. This seems like a reasonable assumption. Signed-off-by: Jonathan Wakely <jwakely@redhat.com> --- src/b4/__init__.py | 12 ++++++++++++ 1 file changed, 12 insertions(+)