Re: Hashing out the scope of work

On 2024-04-29 12:35, Joseph Myers wrote:
>>>> 6. Patch tracking services (Patchwork)
>>>>
>>>>    a. LF will deploy the latest version of Patchwork patch tracking software
>>>>       under patchwork.coretoolchain.dev.
>>>>    b. LF will set up automation and integration services between mailing lists,
>>>>       patchwork, and git repositories (using [git-patchwork-bot][8]).
>>>>    c. LF will work with the glibc community to set up projects and access as
>>>>       appropriate.
>>>
>>> The existing glibc Patchwork database should be transitioned across.
>>
>> Can you give more information why this is desired? This is uncharted
>> territory and I'm not sure how much effort this would require.
> 
> The same reason as anything else.  Patches from before the transition are
> just as much in need of review as those from after the transition, so the
> state of review of those patches should be maintained across the
> transition.
> 
> I don't really think of moving patch review state or bug database state
> across as substantially different from moving the existing git repository
> - these are all key parts of the development process and shouldn't have an
> artificial divide based on the details of when hosting changed, once the
> transition happens developers should only need to interact with the new
> system, for tracking state of old or new patches, for updating state of
> old or new bugs.

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.

If the active patch backlog is a concern then maybe we could refer to 
both instances for a while in the patch review call and move over 
completely at the end of that period.  I don't remember ever managing to 
actually run through the full backlog (that currently stands at 469 
patches) during any review session.

Sid