Re: Hashing out the scope of work

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?  

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

I don't mind doing this work as long as everyone understands that it's 
probably a couple of weeks worth of effort and we have to budget it as 
such.

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

-K