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
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. * 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. :) * 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. .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
-- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
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
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
On 2019-09-30 12:17:46, Gaba wrote:
A reminder that this meeting is tomorrow (October 1st) at 17UTC.
Sorry, but I hadn't that penned down in my agenda, and I have another appointment tomorrow at the same time. I see now (but didn't notice then) that the date was announced when the minutes were last sent (but not the time)... Is there a way to shift this around? Otherwise I won't be able to attend, which is okay too I suppose. :) A. -- Antoine Beaupré torproject.org system administration
On 2019-09-30 15:26:22, Antoine Beaupré wrote:
On 2019-09-30 12:17:46, Gaba wrote:
A reminder that this meeting is tomorrow (October 1st) at 17UTC.
Sorry, but I hadn't that penned down in my agenda, and I have another appointment tomorrow at the same time.
I see now (but didn't notice then) that the date was announced when the minutes were last sent (but not the time)...
Is there a way to shift this around? Otherwise I won't be able to attend, which is okay too I suppose. :)
After a quick chat with gaba on IRC, I would like to propose we postpone this to 18UTC, same day. Is that alright with everyone? Thanks! a. -- Antoine Beaupré torproject.org system administration
participants (3)
-
Antoine Beaupré -
Gaba -
Hans-Christoph Steiner