[tor-project] gitlab next steps

[Gaba]

A reminder that this meeting is tomorrow (October 1st) at 17UTC.

Tentative agenda here: https://pad.riseup.net/p/e-q1GP43W4gsY_tYUNxf


El 9/17/19 a las 12:47 PM, Gaba escribió:
> 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