Re: Hashing out the scope of work

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.

We definitely need the various local fields (and, as applicable, sets of 
field values) from the existing Bugzilla.  (If anything, glibc is simpler 
than some cases.  GCC, binutils, GDB need all of the host/target/build 
fields.  glibc isn't itself a compiler so normally only one system, 
strictly "host" for glibc, is relevant, though there *can* be build issues 
where the build system is relevant; "target" doesn't properly apply at 
all.)

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.

The REST API needs to be enabled (I'm assuming this Bugzilla version has 
it); we rely on it to generate lists of fixed bugs, at least.

New bugs should have numbers in ranges well above those used by the 
current Sourceware Bugzilla (e.g. 100000-plus) to avoid near-term 
confusion with the same bug number having different meanings in the two 
databases.

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

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

-- 
Joseph S. Myers
[email protected]