Development discussions
Wed, 03 Mar 2021, 04:53am #1
I2P Legend

This is a thread to discuss the topic of moving tickets and information from the trac instance at trac.i2p2.de to either a trac instance elsewhere or to my gitlab instance. The motivation for this on my part is to make it easier to service issues with the issue tracking software if and when they arise since my ability to maintain our current trac is limited.

There are at least a handful of things that will need to be discussed and milestones which will need to be set and met to complete this process. Some passing discussion has happened in the git thread already. The key complication I've seen seems to be that our trac tickets don't map 1:1 with our gitlab projects. Not that big a deal, though, we could add tags to issues in Gitlab to indicate which application they are in.

Thu, 04 Mar 2021, 01:59pm #2
I2P Legend

Having it all hosted on the same gitlab instance would make life a bit easier.

Thu, 11 Mar 2021, 08:06pm #3
I2P Legend

That is the idea. Also I can much more readily offer support on Gitlab than Trac, I simply have more power to fix things on services I run myself.

WIP: Trac Project => Git Project Map

Map of Trac Tickets by Component to Gitlab Issues by Application+Tag

 * api
- crypto (4) * i2p.i2p #crypto
- general (4) * i2p.i2p #general-migrated
- i2cp (4) * i2p.i2p #i2cp
- naming (1) * i2p.i2p #naming
- utils (10) * i2p.i2p #utils, i2p.scripts
* apps
- BOB (3) * i2p.i2p #BOB
- SAM (4) * i2p.i2p #SAM
- addressbook (3) * i2p.i2p #addressbook
- android (38) * i2p.i2p #android
- console (40) * i2p.i2p #console
- desktopgui (1) * i2p.i2p #desktopgui
- i2psnark (54) * i2p.i2p #i2psnark
- i2ptunnel (39) * i2p.i2p #i2ptunnel
- jetty (5) * i2p.i2p #jetty
- other (5) * i2p.i2p #other-migrated
- plugins (68) * i2p.i2p #plugins-migrated OR Move to respective plugin repositories
- susidns (4) * i2p.i2p #susidns
- susimail (14) * i2p.i2p #susimail
- syndie (14) * i2p.i2p #syndie-legacy
- systray (3) * i2p.i2p #systray
* installer (28) * i2p.i2p #installer
* other (14) * TO_BE_DETERMINED
* package
- debian (14) * i2p.i2p #installer-debian
- other (1) * i2p.i2p #installer-other
- slackware (0) * i2p.i2p #installer-slackware
- ubuntu (0) * i2p.i2p #installer-ubuntu
* router
- general (57) * i2p.i2p #general
- netdb (12) * i2p.i2p #netdb
- transport (71) * i2p.i2p #transport
- update (8) * i2p.i2p #updater
* streaming (12) * i2p.i2p #streaming
* trac (3) * NOT_APPLICABLE
* wrapper (6) * i2p.i2p #wrapper
* www
- debianrepo (0) * i2p.services #debian
- i2p (32) * i2p.www
- reseed (0) * reseed-tools
- syndie (0) * NOT_APPLICABLE
* uncategorized
- unspecified (5) * TO_BE_DETERMINED

IMO www issues should be changed from the Trac MO, where all web services get the www tag, to just site issues and other things should be moved to either component repositories(reseed-tools) or new repositories(i2p.services) where they can be tracked independently of the Web Site.

Last edited: Thu, 11 Mar 2021, 08:17pm by idk

Fri, 12 Mar 2021, 02:55pm #4

good work, looks fine

does it make sense to add the tags and milestones (releases) to gitlab now, or will that all get filled in by tor's migration tools?

Sun, 14 Mar 2021, 01:51pm #5
I2P Legend

I'm almost sure it doesn't matter, you may create tags on new issues or not as you see fit. I should be able to both scenarios, whether a tag already exists or not.

Mon, 15 Mar 2021, 11:26am #6

I certainly don't want to create all the tags and milestones manually, nor do I want to interfere with a future automated creation, or conflict with whatever style or syntax you come up with.

You haven't shared a proposed schedule for the migration, but if it's going to be a long time, I suggest that it may be helpful to do some scripted creation of the tags and milestones early in the process, both to make gitlab tickets more useful now, and to help evaluate some of the latter migration steps.

Mon, 15 Mar 2021, 06:48pm #7
I2P Legend

What I mean to imply by "It doesn't matter" is that I should be able to gracefully resolve any conflicts that arise, that should not be a problem for me. The tags from the map I made above are the tags that I plan to use, so if you have an issue you want to track on gitlab which you want to apply one of those tags to, please feel free to do so before trac migration.

As for a schedule, I don't think in certain ways it really *can* be a long time, as in, if I'm automatically migrating a bunch of tickets from many "Components" to few git "Repositories" with tags corresponding to the components, then I should do components who's source resides in i2p.i2p roughly at the same time, and that accounts for the overwhelming majority of the tickets on trac. There will be a day when a couple hundred tickets get moved from trac to gitlab all at once, leaving only a handful of i2p.www and i2p.android related components and the trac wiki to migrate. That it would be so many individual things being moved from one place to the other, and because we have not had the meeting about trac yet, are the reasons I haven't put up a schedule.

Mon, 15 Mar 2021, 07:01pm #8
I2P Legend

Oh also, one day before the trac migration I would like to shutdown gitlab for one hour while I take a snapshot of the disk.

Thu, 29 Apr 2021, 10:40pm #9
I2P Legend

So in the time it took for me to move on this trac xmlrpc broke, so I had to re-do all the software parts of the trac migration in a way that didn't depend on trac working right, because trac never works right. Tonight, there will be a flood of trac issues migrated to gitlab. It will be considerable. If you're getting e-mails, and you've subscribed in such a way that you follow all activity on the site, expect your e-mail inbox to be flooded. If you're not getting e-mails I'll get to those next.

Fri, 30 Apr 2021, 04:36am #10
I2P Legend

Also, since I had to re-write half the tools, I can do it more incrementally now. Specifically I can do it on a component/category basis. i2p.www is now copied from trac to gitlab, as are installer and netdb issues on i2p.i2p. I left links to trac intact in the comments for the time being. I did not preserve ownership by equating trac ownership with gitlab assignment because many owners were not present. I do leave the owner of the trac ticket in the body of the issue. I self-assigned several of mine as I migrated the tickets to issues.

Last edited: Fri, 30 Apr 2021, 04:53am by idk