Re: Hashing out the scope of work

[Joseph Myers <josmyers@redhat.com>]

On Tue, 30 Apr 2024, Konstantin Ryabitsev wrote:

> On Mon, Apr 29, 2024 at 09:58:18PM GMT, Joseph Myers wrote:
> > > For example, for bugzilla we'd need to prepare a query to filter 
> > > bugs and comments by product and component -- to only include those 
> > > belonging to glibc. However, how do we go about filtering users? 
> > > User records are not tied to a specific product or component. We can 
> > > try to have a large query limiting the users to just those accounts 
> > > who have commented on glibc bugs, but this is going to be hairy -- 
> > > someone could have commented on a bug that started out filed under a 
> > > different product/component.
> > 
> > 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).

If an account was blocked for spamming and gets copied, it should still be 
blocked after the move.

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

-- 
Joseph S. Myers
josmyers@redhat.com