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