gilab migration (was: Re: Thanks!)

Jean-Marc Lasgouttes lasgouttes.lyx.org at free.fr
Fri Nov 11 16:04:41 UTC 2022


Le 14/10/2022 à 14:42, Joel Kulesza a écrit :
> Yes, I'm still hoping for replies to my March 8 email 
> (https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg217242.html 
> <https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg217242.html>) 
> and more narrowly my developer-list July 14 email.  Notably, I didn't 
> receive any user accounts other than JMarc's to add to the private 
> project to get additional feedback (or I missed them and cannot find 
> them, and I apologize if that's the case).  Nevertheless, since March 8 
> and within the developer-list thread following some additional 
> discussion, I made the example issue migration public (here: 
> https://gitlab.com/jkulesza/test_export_import/-/issues 
> <https://gitlab.com/jkulesza/test_export_import/-/issues>) but have 
> received no feedback subsequently.  So, I am "stuck" between my March 
> 8th steps 2 and 3.
> 
> What I would propose at this point unless someone gives the feedback 
> that what's shown is unworkable, no good, etc., is to cleanup my 
> migration script, see if I can incorporate attachments and ensure issue 
> number correspondence, and prove out the process again.  If/when proven, 
> we'll be at the point of deciding whether to actually perform the 
> migration, or not.  Because of current work conditions, I'm unsure about 
> the timing of this, but unless I hear objections I'll pursue this plan.

Hi Joel,

I finally took some time to look again at the migration status, and here 
is my shopping list. Please tell us what is easy, doable, difficult, 
undoable, you name it.

I'll start from the top of the page of
https://gitlab.com/jkulesza/test_export_import/-/issues/1529
It might have been better to see more recent bugs, that do not date from 
bugzilla times and link to git commits.

I encourage my fellow developers to ask for access and chime in :)


Let's go for the list of things I'd like to see :

* issue number: it should be the same as in trac. It is weird actually 
that the gitlab issue number is larger than the trac one, I would have 
expected the opposite, due to deleted trac tickets

* issue date : should be the same as trac

* issue reporter : ditto

* the status of the tickets should be kept (transformed to labels if I 
understand well).

* the bug description: basically everything that is there should go to 
the proper place (see below)

* let's have a look at the table in the header. I can separate the 
entries in several categories

   - those who can go elsewhere: submitted (ticket date), reporter 
(created by), owner by (assignee), milestone (milestone), CC (notifications)

   - those that can maybe become labels : component, version (unless 
there is something I miss in gitlab for that)

   - those that can go away : last modified

   - those that I do not know how to handle (does gitlab handle that?) : 
priority, severity (maybe labels?)

* attachments: is there some ntive gitlab thing for that? If yes, 
attachments should be imported.

* Description : should be kept there

* Change history : comments should be individual gitlab comments, 
ideally with proper author name and date.

* the history of ticket (changes to properties) should be transferred 
(gitlab entries like "lasgouttes added label "regression" 1 month ago). 
That means that ideally the whole history of tickets should still be 
available.


This is of course very long and very demanding. This explains why I did 
not ask earlier, it felt like whining that your work was not good enough ;)

Thanks for the effort,
JMarc



More information about the lyx-devel mailing list