Re: Hashing out the scope of work

[Joseph Myers <josmyers@redhat.com>]

On Mon, 29 Apr 2024, Konstantin Ryabitsev wrote:

> > We need some form of (fully free software) spam protection, whether the 
> > existing scheme where new accounts need to be manually requested and 
> > approved, or any other sufficiently reliable spam protection scheme 
> > available upstream.
> 
> There isn't any. \o/
> We run bugzilla-junker that goes through all recent comments and lets 
> the admin review all URLs for spam content. It's pretty effective at 
> keeping our bugzilla instance spam-free.
> https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/bugzilla-junker.py

Before we restricted account creation, at one point GCC Bugzilla had 
spammers opening new bugs faster than the REST API could mark them as 
spam.  While I think Sourceware passes comments through SpamAssassin, my 
expectation is that we need manually reviewed account creation (i.e. 
people sending emails to create accounts, with enough information to 
convince people they're not a spammer) to avoid very high spam volumes.

> > There may be an unresolved question about migrating existing glibc 
> > bugs (all of them, or at least the open ones) from the Sourceware 
> > Bugzilla (keeping their numbers); I think such migration is valuable, 
> > including for closed bugs (then adding a comment to all the old bugs 
> > that they are frozen and future discussion should take place at the 
> > new location), but I think there have been suggestions that such 
> > migration is hard.  (Bugs for other products in Sourceware Bugzilla 
> > would not of course be included in such a migration, since the new 
> > database would be glibc-only.)
> 
> This would be super hard and may introduce unwanted side-effects. To my 
> knowledge, it's impossible to lock a bug -- so you may have a 
> split-brain situation where a bug is still updated in the old location, 
> but not in the new location.

A local patch on the Sourceware side (to disallow new changes to bugs in 
the glibc product) could surely have the effect of such locking.

By way of examples of other projects that did issue tracker migrations (to 
GitHub Issues), both LLVM and Python migrated existing issues as part of 
those migrations.  Both those were also changing from one issue tracker 
implementation to another; a migration from Bugzilla to Bugzilla surely 
ought to be simpler because of a closer match between the underlying data 
models (even if the Bugzilla versions are different).  While both were 
able to make the old tracker entirely readonly after the move - they 
didn't have the complication of the old tracker mixing bugs for multiple 
projects - I think that's more of a small detail, not something to make a 
conversion excessively hard.

> > > 6. Patch tracking services (Patchwork)
> > > 
> > >   a. LF will deploy the latest version of Patchwork patch tracking software
> > >      under patchwork.coretoolchain.dev.
> > >   b. LF will set up automation and integration services between mailing lists,
> > >      patchwork, and git repositories (using [git-patchwork-bot][8]).
> > >   c. LF will work with the glibc community to set up projects and access as
> > >      appropriate.
> > 
> > The existing glibc Patchwork database should be transitioned across.
> 
> Can you give more information why this is desired? This is uncharted 
> territory and I'm not sure how much effort this would require.

The same reason as anything else.  Patches from before the transition are 
just as much in need of review as those from after the transition, so the 
state of review of those patches should be maintained across the 
transition.

I don't really think of moving patch review state or bug database state 
across as substantially different from moving the existing git repository 
- these are all key parts of the development process and shouldn't have an 
artificial divide based on the details of when hosting changed, once the 
transition happens developers should only need to interact with the new 
system, for tracking state of old or new patches, for updating state of 
old or new bugs.

-- 
Joseph S. Myers
josmyers@redhat.com