Re: Hashing out the scope of work

[Joseph Myers <josmyers@redhat.com>]

On Mon, 29 Apr 2024, Konstantin Ryabitsev 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.

We do still need to make sure things don't break if migrating a bug that 
was originally reported under a different product/component, whose history 
might thus show changes of product/component/... from values that 
shouldn't need to exist in the new Bugzilla.  But as long as things don't 
break, it's OK for the history display not to show those details of the 
history that aren't meaningful in a glibc-only context - to show them as a 
change from <missing-product> to glibc, for example.

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

-- 
Joseph S. Myers
josmyers@redhat.com