Re: Hashing out the scope of work

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Thu, May 02, 2024 at 07:27:32PM GMT, Joseph Myers wrote:
> > > The simple answer there is not to filter users.  It's OK to have 
> > > more users than necessary in the new database.
> > 
> > Is it okay with the users, though, that they suddenly have accounts on a 
> > totally different system belonging to a totally different organization?  
> 
> If that's a concern, I wouldn't expect it to be particularly hard to 
> identify a more precise set of users: there's a precise set of bugs to 
> copy (i.e. those, whether open or closed, that are against the glibc 
> product at the time of the move - not anything that was once opened 
> against the glibc product but is currently associated with a different 
> product) and each bug has a limited set of relevant people (reporter, 
> assignee, CC, anyone who did any action recorded in the bug's history).

So, I did some more poking at the backend database for bugzilla and 
while I think it's possible, this kind of surgery of moving a single 
project out of a larger instance to a fresh new instance would be a lot 
of effort, and something could still go wrong in ways that aren't 
immediately obvious.

I recommend this course of action:

1. We convert all current bugs in the glibc component of 
sourceware.org/bugzilla to a public-inbox archive, searchable by the bug 
id. This functionality exists in our bugspray project and only requires 
non-privileged REST access to bugzilla.
2. On the migration date, all glibc components at sourceware are closed 
for creating new bugs. This still allows completing existing bug 
entries.
3. The new bugzilla at CTI starts from a fresh state, with bug numbers 
starting with 100000, to indicate a clear break.

This allows us to preserve a searchable archive of all old glibc bugs, 
but does not require doing a database surgery that would be required in 
order to forklift all old bugs from the old bugzilla to the new.

Is that a workable solution?

> > > > The same problem is with patchwork -- migrating just the subset 
> > > > of the database that belongs to glibc lists is going to be very 
> > > > difficult, especially with the kind of data model that patchwork 
> > > > has. Is it the CI data that you want to preserve?
> > > 
> > > I think it's the details of what patches / patch series still need 
> > > review that's the most valuable part to preserve and migrate.
> > 
> > I think we can accomplish this without having to touch the DB. We can 
> > identify the patches that are still open and replay them from the 
> > mailing list into the new system. This would be a lot simpler than doing 
> > database surgery.
> 
> Where patchwork lists patch series as such, is this automatic based on the 
> mailing list messages?  (I think the grouping of patches awaiting 
> review into series is worth preserving.)

Yes, series grouping is automatic based on threading, so can be fully 
recreated from mailing list archives.

-K