Re: Hashing out the scope of work

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Joseph Myers <josmyers@redhat.com>
Cc: Siddhesh Poyarekar <siddhesh@gotplt.org>,
	 cti-tac@lists.linuxfoundation.org
Subject: Re: Hashing out the scope of work
Date: Mon, 29 Apr 2024 17:01:25 -0400	[thread overview]
Message-ID: <20240429-rousing-mamba-of-improvement-cabefb@lemur> (raw)
In-Reply-To: <de67e18-d847-717e-a8d-dbfe7d2044d7@redhat.com>

On Mon, Apr 29, 2024 at 08:47:27PM GMT, Joseph Myers wrote:
> On Mon, 29 Apr 2024, Siddhesh Poyarekar wrote:
> 
> > I believe we had explicitly agreed in a previous CTI TAC meeting to start over
> > with a clean slate for patchwork and not bother with migrating the previous
> > database.
> 
> Bug database migration is definitely a lot more important than patchwork 
> migration, but I think the starting point is that patchwork state should 
> be migrated in the absence of a clear reason that's problematic.  And if 
> it's problematic, we should try to understand if there's a better way to 
> configure the future patchwork installation to make it more 
> susceptible to any future migrations.

The difficulty isn't really in the migration by itself, but in the fact 
that we're taking a single project from a larger installation of 
bugzilla or patchwork and attempting to migrate just that project and 
omit everything else. 

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.

Yanking out just those db entries that belong to glibc is going to be 
super hard -- I'm not even sure surgery like this has even been done 
before. This is really why I'm worried that we will spend a lot of 
effort trying to get it to work only to realize something didn't get 
moved over properly at some later date.

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?

-K