[tor-project] gitlab next steps

[Gaba]

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

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