Re: [tor-project] gitlab next steps

El 9/20/19 a las 5:15 AM, Hans-Christoph Steiner escribió:

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.

Sounds good.

• 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. :)

Yes. That is what anarcat is proposing.

• 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.

Interesting. This could be something to consider for the future.

.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