Re: Hashing out the scope of work

On Mon, Apr 29, 2024 at 02:09:33PM GMT, Joseph Myers wrote:
> On Wed, 24 Apr 2024, Konstantin Ryabitsev wrote:
> 
> > 2. Bug tracking software (Bugzilla)
> > 
> >   a. LF will set up a bug tracking system using [Bugzilla Harmony][2]. This
> >      will be a new, dedicated installation in the bugzilla.coretoolchain.dev
> >      domain.
> >   b. LF will work with the CTI leadership to properly configure the software
> >      for use with the glibc project.
> 
> There will be lots of review needed of the existing Bugzilla configuration 
> and local changes.  Some of those changes may simply be to have more 
> appropriate contents on the bug submission form / other HTML templates, 
> some may involve actual logic changes.  Hopefully the new upstream version 
> is suitably configurable without needing too many local changes.

Definitely, and I would even go further and say that any changes that 
require actual code modifications beyond writing extensions would 
require multiple levels of review before we accept them. In our 
experience, a modified version of bugzilla is a version of bugzilla that 
will never get updated because nobody wants to touch it out of fear of 
breaking something -- so it just ends up unmaintained.

> 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
 
> 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.

> > 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.

-K