[tor-project] gitlab next steps

[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




-- 
Project Manager: Network, Anti-Censorship and Metrics teams
gaba at torproject.org
she/her are my pronouns
GPG Fingerprint EE3F DF5C AD91 643C 21BE  8370 180D B06C 59CA BD19