[tor-project] gitlab next steps

Fri Sep 20 12:15:06 UTC 2019

Sounds like this is moving forward nicely!  I've used GitLab since 2014
and helped migrate F-Droid, Guardian Project, and Debian.  I've also
been writing bots for gitlab, so I know something about its API.  Please
ping me if you want to run any questions by me.  I'll try to follow the
whole process as well, as I find time, since I'm not a Tor employee or
contractor.

* I think there should be at least as 24 hour issue tracker down time, 2
days or longer would be more realistic.  Live migrations are vastly more
work to pull off.

* About maintaining the existing ticket numbers, my guess is that the
easiest approach will be to find a way to create all trac issues in the
"tor" project on gitlab sequentially so it maintains the same number.
Perhaps you're doing that already. :)

* There is a potential other, more involved approach: gitlab internally
uses ticket IDs like trac, where there is one global counter that is
incremented for each new issue.  In the Debian context
(salsa.debian.org), it would be very interesting to have that global
issue number exposed in the UI somehow since the Debian BTS also uses
global issue IDs.  Perhaps there is the possibility of Debian and Tor
teaming up to create this feature.  This would probably require a grant
though, or some very interested volunteer Ruby coders.

.hc

Gaba:
> Hi!
> 
> We met today to talk about the migration from trac into gitlab. The
> agenda and notes are in the pad
> (https://pad.riseup.net/p/e-q1GP43W4gsY_tYUNxf) and in the body of this
> mail.
> 
> You can look at the logs for the meeting in:
> http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-09-17-18.01.html
> 
> 
> Next meeting will be on October 1st.
> 
> 
> CONTENT OF THE PAD:
> 
> References:
>     mail with context:
> https://lists.torproject.org/pipermail/tor-project/2019-July/002407.html
>     planning document: https://nc.riseup.net/s/SnQy3yMJewRBwA7
>     migration code: https://dip.torproject.org/ahf/trac-migration
>     ticket: https://trac.torproject.org/projects/tor/ticket/30857
> 
> 
> Agenda September 17th
> 
> * Revisit agenda
> * Update that where we are at
> * Stuff that seems that still needs to be resolved or decided upon:
>     * IRC ticket number bot
>     * redirection from bugs.torproject.org to gitlab ticket (legacy
> project resolve links?)
>     * structure for projects
>     * anonymous users/ user registration
>     * Preserving existing trac data
> 
>      * data migration process
> 
> * Next steps
> 
> Notes
> 
> Logs:
> http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-09-17-18.01.html
> 
> On ticket numbers:
> 
> 1) IRC bot for tickets (zwiebelbot) - get ticket's title and a link to
> the ticket when we write #TICKET-NUMBER. In gitlab tickets are per project.
> 
>     possible solutions:
> 
>     1.  write a plug-in for the bot that is running zwiebelbot to fetch
> the data via gitlab's api. we will lose the short hand ticket id syntax
> (#xxx) and have to use project-name#xxx instead with that
> 
> 
> 2) redirect from bugs.torproject.org/#TICKET-NUMBER to the right issue
> in gitlab
> 
>     possible solutions:
> 
>     1. a part of the migration from tickets from trac to all the
> different gitlab project, we save a mapping between the old ticket ID's
> and their new project paths, which would allow us to update the
> redirection service with a tool that looks at htis mapping and does the
> redirect
> 
>     2. all tickets first get migrated to a single project where there's
> a one to one mapping between ticket IDs in trac and gitlab so bugs.tpo/N
> point to dip.tpo/legacy/N
> 
>     for future issues (not legacy) we will have
> bugs.torproject.org/project/NNN
> 
> 
> 3) the question is how to keep ticket numbers consistent across the
> migration if we want to have tickets split between mut roject
> 
> 
> Nick's Absolute Requirements:
>        1. If there is #NN in trac, and there is tor#NN in gitlab, then
> they must be the same bug.
>        2. If there is tor#MM in gitlab, and it is the same as some bug
> #NN in trac, then MM must equal NN.
> 
> 
> NEXT STEP: AHF will experiment with aproach 2.2 on moving tickets from
> legacy project into its own. (ahf will move forward)
> 
> Structure for projects:
> 
>     Proposed structure:
> 
> 
> 
>     Group TEAM X  - all team members have ownership on this group.
> 
>             Project X1 - the ones related to repositories. Example:
> snowflake or little-t tor.
> 
>             Group XX1 - example pluggable transports for anti-censorship
> team
> 
>     Project Y - at organization level, example scalability that may
> touch all teams.
> 
> 
> NEXT STEP: rename the group 'torproject' to tpo (gaba will do it)
> NEXT STEP: add the rule "do not have two elements in the project naming
> tree with the same name, even if they are not ambiguous"
> NEXT STEP: add the rule "short names when possible for projects or groups"
> 
> Anonymous users/ user registration:
> 
> Options:
> (1) cypherpunks - people not ok with this one as there are trolls
> (2) salsa custom signup form  - some people say this is not totally
> effective
> (3) akismet + recaptcha - not really an option because it blocks tor
> users and tracks people
> (4) write a custom captcha plugin  - some people say this is not totally
> effective
> (5) open registration - spam is a huge issue here
> 
> Proposals:
> 
>     1) i suggest we manually register gitlab accounts for known good
> contributors and open up contributions from github issues (from catalyst)
> 
>     2) open registration with some spam-limiter, and moderate accounts
> (from nick)
> 
>     3) consider experimenting with the salsa custom signup form
> 
> 
> NEXT STEP: We need more research on how to deal with spam in gitlab.
> NOTHING DECIDED YET. (gaba will check)
> 
> Preserving existing trac data:
> 
> NEXT STEP with a list of things that you will not see in gitlab from trac
> 
> Data migration process:
> 
> NEXT STEP: write down a more concrete plan for migration. What do we
> test for? When we do it? Who is helping? - (gaba will do it)
> 
> 
> Issues about migration will be deal here:
> https://dip.torproject.org/ahf/trac-migration
> 
> 
> 
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556