Hi!
There has been some discussion in the 'corridors' of Tor and in the last meeting face to face during the session on 'internal tooling' and specifically about tickets system. I'm sending this mail to try to summarize what the discussion has been until now, make it transparent and try to get an agreement on how to move forward.
Problem: - Trac software is not being mantained (from our perspective of users of Trac this is a bomb getting ready to explode) [0]
Solution - Move out into a better (possible feature parity with what we use now AND integration between project management tool and tickets) and mantained ticketing system.
Discussion until now - A few years ago there was a survey [1] on which features people would like to see in a new ticketing system. - There is a ticket [2] that has a discussion on features needed and a document [3] that brainstorm features between trac and gitlab. - The last meeting in Stockholm there has been several discussions on what is needed. [4] - In 2017 Hiro and the network team experimented with the oniongit.eu Gitlab instance. - In 2019, a test instance was setup, called "dip.torproject.org"[5], that a few projects are using right now to test its use.
We are mostly considering Gitlab (until now) because: 1. We can host it ourselves and not have other company control the data. 2. It is open source [6]. 3. It is mantained [7]. 4. It supports the project management tool that we are interested in.
Before moving forward we need: 1. Consensus or a clear compromise on what to move into. 2. A plan on how the migration to a new ticketing system will happen. I started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
cheers, gaba
[0] https://trac.edgewall.org/roadmap [1] https://docs.google.com/spreadsheets/d/1V4Faq2y9vv8XTp-OADl4YRMTiRB0G9DHvj23... [2] https://trac.torproject.org/projects/tor/ticket/30857 [3] https://nc.riseup.net/s/TYX37BDT4eQfTiW [4] https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Not... [5] https://dip.torproject.org [6] https://gitlab.com/gitlab-org [7] https://gitlab.com/groups/gitlab-org/-/roadmap?layout=MONTHS [8] https://nc.riseup.net/s/SnQy3yMJewRBwA7
Hi,
I'd like to suggest another step:
On 30 Jul 2019, at 01:07, Gaba gaba@torproject.org wrote:
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
3. A test migration, so we can check that our plan works the way that we expect.
T
Hi!
With Pili we have been working on this document to compare features between trac and gitlab as well as proposal for a structure and workflows. Please take a look and send comments/feedback/edits/adds/questions.
https://nc.riseup.net/s/SnQy3yMJewRBwA7
It seems that the next step will be to get together between everybody interested in this transition (or in not doing it) and discuss this plan as well as how to move forward.
We are going to meet on
September 17th, at 18UTC in #tor-meeting
Please, send me, pili or to the mailing list any comment if you can not make it to the meeting.
cheers, gaba
El 7/29/19 a las 8:07 AM, Gaba escribió:
Hi!
There has been some discussion in the 'corridors' of Tor and in the last meeting face to face during the session on 'internal tooling' and specifically about tickets system. I'm sending this mail to try to summarize what the discussion has been until now, make it transparent and try to get an agreement on how to move forward.
Problem:
- Trac software is not being mantained (from our perspective of users of
Trac this is a bomb getting ready to explode) [0]
Solution
- Move out into a better (possible feature parity with what we use now
AND integration between project management tool and tickets) and mantained ticketing system.
Discussion until now
- A few years ago there was a survey [1] on which features people would
like to see in a new ticketing system.
- There is a ticket [2] that has a discussion on features needed and a
document [3] that brainstorm features between trac and gitlab.
- The last meeting in Stockholm there has been several discussions on
what is needed. [4]
- In 2017 Hiro and the network team experimented with the oniongit.eu
Gitlab instance.
- In 2019, a test instance was setup, called "dip.torproject.org"[5],
that a few projects are using right now to test its use.
We are mostly considering Gitlab (until now) because:
- We can host it ourselves and not have other company control the data.
- It is open source [6].
- It is mantained [7].
- It supports the project management tool that we are interested in.
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
cheers, gaba
[0] https://trac.edgewall.org/roadmap [1] https://docs.google.com/spreadsheets/d/1V4Faq2y9vv8XTp-OADl4YRMTiRB0G9DHvj23... [2] https://trac.torproject.org/projects/tor/ticket/30857 [3] https://nc.riseup.net/s/TYX37BDT4eQfTiW [4] https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Not... [5] https://dip.torproject.org [6] https://gitlab.com/gitlab-org [7] https://gitlab.com/groups/gitlab-org/-/roadmap?layout=MONTHS [8] https://nc.riseup.net/s/SnQy3yMJewRBwA7
Hi Gaba, would you mind adding a section that discusses 'Gitlab vs Github'? I realize some folks feel self-hosting is a must, but I value other equities more (like prevalence within the wider open source community and migration redirects).
Ooni chose GitHub [1] and the Network Team has partially migrated in that direction as well [2]. I'd like to give Gitlab a fair shake, but I'm not spotting where within the planning doc we persuasively pitch for Gitlab over its alternatives (and by extension why my subprojects shouldn't follow Ooni and the Network Team's lead as trac is decommissioned).
Thanks! -Damian
[1] https://ooni.torproject.org/get-involved/ [2] https://github.com/torproject
On Fri, Sep 6, 2019 at 1:52 PM Gaba gaba@torproject.org wrote:
Hi!
With Pili we have been working on this document to compare features between trac and gitlab as well as proposal for a structure and workflows. Please take a look and send comments/feedback/edits/adds/questions.
https://nc.riseup.net/s/SnQy3yMJewRBwA7
It seems that the next step will be to get together between everybody interested in this transition (or in not doing it) and discuss this plan as well as how to move forward.
We are going to meet on
September 17th, at 18UTC in #tor-meeting
Please, send me, pili or to the mailing list any comment if you can not make it to the meeting.
cheers, gaba
El 7/29/19 a las 8:07 AM, Gaba escribió:
Hi!
There has been some discussion in the 'corridors' of Tor and in the last meeting face to face during the session on 'internal tooling' and specifically about tickets system. I'm sending this mail to try to summarize what the discussion has been until now, make it transparent and try to get an agreement on how to move forward.
Problem:
- Trac software is not being mantained (from our perspective of users of
Trac this is a bomb getting ready to explode) [0]
Solution
- Move out into a better (possible feature parity with what we use now
AND integration between project management tool and tickets) and mantained ticketing system.
Discussion until now
- A few years ago there was a survey [1] on which features people would
like to see in a new ticketing system.
- There is a ticket [2] that has a discussion on features needed and a
document [3] that brainstorm features between trac and gitlab.
- The last meeting in Stockholm there has been several discussions on
what is needed. [4]
- In 2017 Hiro and the network team experimented with the oniongit.eu
Gitlab instance.
- In 2019, a test instance was setup, called "dip.torproject.org"[5],
that a few projects are using right now to test its use.
We are mostly considering Gitlab (until now) because:
- We can host it ourselves and not have other company control the data.
- It is open source [6].
- It is mantained [7].
- It supports the project management tool that we are interested in.
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
cheers, gaba
[0] https://trac.edgewall.org/roadmap [1] https://docs.google.com/spreadsheets/d/1V4Faq2y9vv8XTp-OADl4YRMTiRB0G9DHvj23... [2] https://trac.torproject.org/projects/tor/ticket/30857 [3] https://nc.riseup.net/s/TYX37BDT4eQfTiW [4] https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Not... [5] https://dip.torproject.org [6] https://gitlab.com/gitlab-org [7] https://gitlab.com/groups/gitlab-org/-/roadmap?layout=MONTHS [8] https://nc.riseup.net/s/SnQy3yMJewRBwA7
-- 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 _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
That makes sense. I will add a section on other possible platforms to move to.
The network team has the mirror in github but did not move to github or is planning to right now.
Damian Johnson:
[1] and the Network Team has partially migrated in that direction as well [2]. I'd like to give Gitlab a fair shake, but I'm not spotting where within the planning doc we pe
El 9/7/19 a las 3:28 PM, Damian Johnson escribió:
Hi Gaba, would you mind adding a section that discusses 'Gitlab vs Github'? I realize some folks feel self-hosting is a must, but I value other equities more (like prevalence within the wider open source community and migration redirects).
Hi!
I added a section to compare with other platforms like Github. Do you mind look at it and fill in what you think is comparable?
Ooni chose GitHub [1] and the Network Team has partially migrated in that direction as well [2]. I'd like to give Gitlab a fair shake, but I'm not spotting where within the planning doc we persuasively pitch for Gitlab over its alternatives (and by extension why my subprojects shouldn't follow Ooni and the Network Team's lead as trac is decommissioned).
Thanks! -Damian
[1] https://ooni.torproject.org/get-involved/ [2] https://github.com/torproject
On Fri, Sep 6, 2019 at 1:52 PM Gaba gaba@torproject.org wrote:
Hi!
With Pili we have been working on this document to compare features between trac and gitlab as well as proposal for a structure and workflows. Please take a look and send comments/feedback/edits/adds/questions.
https://nc.riseup.net/s/SnQy3yMJewRBwA7
It seems that the next step will be to get together between everybody interested in this transition (or in not doing it) and discuss this plan as well as how to move forward.
We are going to meet on
September 17th, at 18UTC in #tor-meeting
Please, send me, pili or to the mailing list any comment if you can not make it to the meeting.
cheers, gaba
El 7/29/19 a las 8:07 AM, Gaba escribió:
Hi!
There has been some discussion in the 'corridors' of Tor and in the last meeting face to face during the session on 'internal tooling' and specifically about tickets system. I'm sending this mail to try to summarize what the discussion has been until now, make it transparent and try to get an agreement on how to move forward.
Problem:
- Trac software is not being mantained (from our perspective of users of
Trac this is a bomb getting ready to explode) [0]
Solution
- Move out into a better (possible feature parity with what we use now
AND integration between project management tool and tickets) and mantained ticketing system.
Discussion until now
- A few years ago there was a survey [1] on which features people would
like to see in a new ticketing system.
- There is a ticket [2] that has a discussion on features needed and a
document [3] that brainstorm features between trac and gitlab.
- The last meeting in Stockholm there has been several discussions on
what is needed. [4]
- In 2017 Hiro and the network team experimented with the oniongit.eu
Gitlab instance.
- In 2019, a test instance was setup, called "dip.torproject.org"[5],
that a few projects are using right now to test its use.
We are mostly considering Gitlab (until now) because:
- We can host it ourselves and not have other company control the data.
- It is open source [6].
- It is mantained [7].
- It supports the project management tool that we are interested in.
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
cheers, gaba
[0] https://trac.edgewall.org/roadmap [1] https://docs.google.com/spreadsheets/d/1V4Faq2y9vv8XTp-OADl4YRMTiRB0G9DHvj23... [2] https://trac.torproject.org/projects/tor/ticket/30857 [3] https://nc.riseup.net/s/TYX37BDT4eQfTiW [4] https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Not... [5] https://dip.torproject.org [6] https://gitlab.com/gitlab-org [7] https://gitlab.com/groups/gitlab-org/-/roadmap?layout=MONTHS [8] https://nc.riseup.net/s/SnQy3yMJewRBwA7
-- 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 _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
I'd like to chime in to say that going with self-hosted gitlab does not mean that Tor Project must be entirely cutoff from GitHub. With mirrors of repos on GitHub, a lot of the integrations will still work, albeit not all.
* it is possible to accept and close pull requests if the commits are unchanged and merged via merge commit
* it is possible to links issues and pull requests in commit messages, using the full URL, e.g. https://github.com/foo/bar/issues/123 and GitHub will do all the normal things with it
* Travis, Circle, etc. can still run on GitHub pull requests when it is just a mirror
Guardian Project and F-Droid have different variants of GitLab+GitHub integration.
.hc
Gaba:
El 9/7/19 a las 3:28 PM, Damian Johnson escribió:
Hi Gaba, would you mind adding a section that discusses 'Gitlab vs Github'? I realize some folks feel self-hosting is a must, but I value other equities more (like prevalence within the wider open source community and migration redirects).
Hi!
I added a section to compare with other platforms like Github. Do you mind look at it and fill in what you think is comparable?
Ooni chose GitHub [1] and the Network Team has partially migrated in that direction as well [2]. I'd like to give Gitlab a fair shake, but I'm not spotting where within the planning doc we persuasively pitch for Gitlab over its alternatives (and by extension why my subprojects shouldn't follow Ooni and the Network Team's lead as trac is decommissioned).
Thanks! -Damian
[1] https://ooni.torproject.org/get-involved/ [2] https://github.com/torproject
On Fri, Sep 6, 2019 at 1:52 PM Gaba gaba@torproject.org wrote:
Hi!
With Pili we have been working on this document to compare features between trac and gitlab as well as proposal for a structure and workflows. Please take a look and send comments/feedback/edits/adds/questions.
https://nc.riseup.net/s/SnQy3yMJewRBwA7
It seems that the next step will be to get together between everybody interested in this transition (or in not doing it) and discuss this plan as well as how to move forward.
We are going to meet on
September 17th, at 18UTC in #tor-meeting
Please, send me, pili or to the mailing list any comment if you can not make it to the meeting.
cheers, gaba
El 7/29/19 a las 8:07 AM, Gaba escribió:
Hi!
There has been some discussion in the 'corridors' of Tor and in the last meeting face to face during the session on 'internal tooling' and specifically about tickets system. I'm sending this mail to try to summarize what the discussion has been until now, make it transparent and try to get an agreement on how to move forward.
Problem:
- Trac software is not being mantained (from our perspective of users of
Trac this is a bomb getting ready to explode) [0]
Solution
- Move out into a better (possible feature parity with what we use now
AND integration between project management tool and tickets) and mantained ticketing system.
Discussion until now
- A few years ago there was a survey [1] on which features people would
like to see in a new ticketing system.
- There is a ticket [2] that has a discussion on features needed and a
document [3] that brainstorm features between trac and gitlab.
- The last meeting in Stockholm there has been several discussions on
what is needed. [4]
- In 2017 Hiro and the network team experimented with the oniongit.eu
Gitlab instance.
- In 2019, a test instance was setup, called "dip.torproject.org"[5],
that a few projects are using right now to test its use.
We are mostly considering Gitlab (until now) because:
- We can host it ourselves and not have other company control the data.
- It is open source [6].
- It is mantained [7].
- It supports the project management tool that we are interested in.
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
cheers, gaba
[0] https://trac.edgewall.org/roadmap [1] https://docs.google.com/spreadsheets/d/1V4Faq2y9vv8XTp-OADl4YRMTiRB0G9DHvj23... [2] https://trac.torproject.org/projects/tor/ticket/30857 [3] https://nc.riseup.net/s/TYX37BDT4eQfTiW [4] https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Not... [5] https://dip.torproject.org [6] https://gitlab.com/gitlab-org [7] https://gitlab.com/groups/gitlab-org/-/roadmap?layout=MONTHS [8] https://nc.riseup.net/s/SnQy3yMJewRBwA7
-- 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 _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hi,
On 7 Sep 2019, at 06:52, Gaba gaba@torproject.org wrote:
With Pili we have been working on this document to compare features between trac and gitlab as well as proposal for a structure and workflows. Please take a look and send comments/feedback/edits/adds/questions.
https://nc.riseup.net/s/SnQy3yMJewRBwA7
It seems that the next step will be to get together between everybody interested in this transition (or in not doing it) and discuss this plan as well as how to move forward.
We are going to meet on
September 17th, at 18UTC in #tor-meeting
Please, send me, pili or to the mailing list any comment if you can not make it to the meeting.
Here are my comments:
1. The document is really long, and I don't have time to read it all in detail.
What's the best way to get: * a summary of what is happening, * the big changes between trac and gitlab, and * the important things we will lose if we move to gitlab * anything else I will be surprised or disappointed to learn later
2. What about ticket numbers?
The proposal is to change all the ticket numbers when we move to gitlab. For many of us that's a blocker, or a huge process change.
Is there any way we can preserve ticket numbers?
If not, what tools are we going to use to make that change easier? For example, we could make bugs.torproject.org redirect the trac ticket numbers to the correct ticket in gitlab.
4. How are we going to replace wiki pages with ticket queries?
The network team (and some other teams) use a lot of wiki pages with ticket queries to track status.
Are we going to replace these wiki pages with Kanbans? Can a ticket be on multiple Kanbans in different places? (For example, a CI ticket might be on the CI Kanban, and the release Kanban.)
5. What about testing the migration?
Here are the "next steps" from your last email, and my suggested "test" step:
On 30 Jul 2019, at 01:07, Gaba gaba@torproject.org wrote:
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
- A test migration, so we can check that our plan works the way that we
expect.
T
El 9/8/19 a las 5:42 PM, teor escribió:
Hi,
On 7 Sep 2019, at 06:52, Gaba gaba@torproject.org wrote:
With Pili we have been working on this document to compare features between trac and gitlab as well as proposal for a structure and workflows. Please take a look and send comments/feedback/edits/adds/questions.
https://nc.riseup.net/s/SnQy3yMJewRBwA7
It seems that the next step will be to get together between everybody interested in this transition (or in not doing it) and discuss this plan as well as how to move forward.
We are going to meet on
September 17th, at 18UTC in #tor-meeting
Please, send me, pili or to the mailing list any comment if you can not make it to the meeting.
Here are my comments:
- The document is really long, and I don't have time to read it all in detail.
What's the best way to get:
- a summary of what is happening,
- the big changes between trac and gitlab, and
- the important things we will lose if we move to gitlab
- anything else I will be surprised or disappointed to learn later
All that is in the document.
- What about ticket numbers?
The proposal is to change all the ticket numbers when we move to gitlab. For many of us that's a blocker, or a huge process change.
Is there any way we can preserve ticket numbers?
If not, what tools are we going to use to make that change easier? For example, we could make bugs.torproject.org redirect the trac ticket numbers to the correct ticket in gitlab.
- How are we going to replace wiki pages with ticket queries?
The network team (and some other teams) use a lot of wiki pages with ticket queries to track status.
Are we going to replace these wiki pages with Kanbans? Can a ticket be on multiple Kanbans in different places? (For example, a CI ticket might be on the CI Kanban, and the release Kanban.)
Releases can be managed with milestones. There will be a board to manage it.
Individulal wiki pages like the one you use can be replaced by filtering the boards we will be using.
- What about testing the migration?
Here are the "next steps" from your last email, and my suggested "test" step:
On 30 Jul 2019, at 01:07, Gaba gaba@torproject.org wrote:
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
- A test migration, so we can check that our plan works the way that we
expect.
T
Yes.
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hi!
A reminder that we are meeting tomorrow September 17th to discuss this proposal of migration from trac.
gaba
El 9/6/19 a las 1:52 PM, Gaba escribió:
Hi!
With Pili we have been working on this document to compare features between trac and gitlab as well as proposal for a structure and workflows. Please take a look and send comments/feedback/edits/adds/questions.
https://nc.riseup.net/s/SnQy3yMJewRBwA7
It seems that the next step will be to get together between everybody interested in this transition (or in not doing it) and discuss this plan as well as how to move forward.
We are going to meet on
September 17th, at 18UTC in #tor-meeting
Please, send me, pili or to the mailing list any comment if you can not make it to the meeting.
cheers, gaba
El 7/29/19 a las 8:07 AM, Gaba escribió:
Hi!
There has been some discussion in the 'corridors' of Tor and in the last meeting face to face during the session on 'internal tooling' and specifically about tickets system. I'm sending this mail to try to summarize what the discussion has been until now, make it transparent and try to get an agreement on how to move forward.
Problem:
- Trac software is not being mantained (from our perspective of users of
Trac this is a bomb getting ready to explode) [0]
Solution
- Move out into a better (possible feature parity with what we use now
AND integration between project management tool and tickets) and mantained ticketing system.
Discussion until now
- A few years ago there was a survey [1] on which features people would
like to see in a new ticketing system.
- There is a ticket [2] that has a discussion on features needed and a
document [3] that brainstorm features between trac and gitlab.
- The last meeting in Stockholm there has been several discussions on
what is needed. [4]
- In 2017 Hiro and the network team experimented with the oniongit.eu
Gitlab instance.
- In 2019, a test instance was setup, called "dip.torproject.org"[5],
that a few projects are using right now to test its use.
We are mostly considering Gitlab (until now) because:
- We can host it ourselves and not have other company control the data.
- It is open source [6].
- It is mantained [7].
- It supports the project management tool that we are interested in.
Before moving forward we need:
- Consensus or a clear compromise on what to move into.
- A plan on how the migration to a new ticketing system will happen. I
started drafting it here (thinking that Gitlab would be the new one) [8]. This plan is still a work in progress and we will continue doing it when we all agree on which system to move into.
cheers, gaba
[0] https://trac.edgewall.org/roadmap [1] https://docs.google.com/spreadsheets/d/1V4Faq2y9vv8XTp-OADl4YRMTiRB0G9DHvj23... [2] https://trac.torproject.org/projects/tor/ticket/30857 [3] https://nc.riseup.net/s/TYX37BDT4eQfTiW [4] https://trac.torproject.org/projects/tor/wiki/org/meetings/2019Stockholm/Not... [5] https://dip.torproject.org [6] https://gitlab.com/gitlab-org [7] https://gitlab.com/groups/gitlab-org/-/roadmap?layout=MONTHS [8] https://nc.riseup.net/s/SnQy3yMJewRBwA7
Hi,
I won't be at the meeting. I've read the migration proposal and the network team feedback pad.
Here is my extra feedback/notes:
Migrate / Test / Rollback * What is the plan for testing the migration? * What data must be successfully transferred? * What is the rollback plan, if the migration fails?
Data migration * how does Parent ID get transferred? * note: will will lose the ability to have multi-level parent/child relationships Proposal: parent-NNNNN tag, placed on child tickets *and* parent ticket
New processes * When we replace fields with tags, how do we ensure consistent milestone, version, etc. spelling?
We might want to use Kanban boards / lanes (or GitLab tasks) rather than: - ticket queries embedded in wiki pages - CI tags - sponsors? - releases? - parent / child tickets?
Ticket ID process changes In Trac, people can use a ticket ID to find a ticket. In GitLab, each project can create *new* tickets with the same ID as tickets in other projects. (Even if we block all Trac ticket numbers, new tickets won't be blocked.) What processes will we need to change, now that ticket IDs need a project? - ChangeLog / ReleaseNotes: ok, project can be determined from context - ticket bot: needs project prefix - can implement search order for non-prefixed numbers: legacy, tor, … - any other contexts?
Migration - existing projects If a project is already set up in GitLab, what do we do with Trac / GitLab ticket number conflicts? Proposal: each project consists of (GitLab tickets before migration)(blocked ticket numbers)(migrated tickets)(new tickets) Proposal: we create a new project for each transferred project, block the Trac ticket numbers out, transfer the legacy tickets, transfer the test project ticket, start opening new tickets
Keyword search Copied from the network team pad: When a field migrates to a keyword, is there a good way to search for tickets lacking any keyword corresponding to that field? gaba: yes. you can filter by issues that do not have a labels (so for example if sponsors are keywords, how do we search for issues with no sponsor keyword? Do we have to list every sponsor keyword?) gaba: there is a value 'None' https://dip.torproject.org/torproject/core/tor/-/boards?scope=all&utf8=%...
New questions: But what if the ticket has *some other* keywords, but no sponsor keyword? We'd need a regex like trac's !~=sponsor It looks like -sponsor or -sponsor* should do what we want, but we should check: https://docs.gitlab.com/ee/user/search/advanced_search_syntax.html
Suggested data migration / test details
Blockers - If these fields aren't transferred as specified, we must roll back.
Ticket number Summary Description Comments (commenter, comment text) Milestone Keywords Actual Points Points Sponsor Component Reviewer
Important - If these fields aren't transferred as specified, they should be fixed as soon as possible.
Type Version Reporter Parent ID - how does Parent ID get transferred?
Optional - It doesn't matter if these fields are transferred or not. - We probably can't transfer these fields in a useful way
Cc Priority Severity Trac magic links to ticket IDs and wiki pages
T
Hi!
El 9/17/19 a las 1:13 AM, teor escribió:
Hi,
I won't be at the meeting. I've read the migration proposal and the network team feedback pad.
Sorry that the time is not right for you.
Here is my extra feedback/notes:
Migrate / Test / Rollback
- What is the plan for testing the migration?
- What data must be successfully transferred?
- What is the rollback plan, if the migration fails?
We need a concrete plan for this. In the meeting today we taked about drafting this.
Data migration
- how does Parent ID get transferred?
- note: will will lose the ability to have multi-level parent/child relationships
Proposal: parent-NNNNN tag, placed on child tickets *and* parent ticket
We still didn't talk about this. I created an issue in ahf's migration repo to look at this https://dip.torproject.org/ahf/trac-migration/issues/1
New processes
- When we replace fields with tags, how do we ensure consistent milestone, version, etc. spelling?
Which one would be the problem? Labels can not be created by anybody. People can apply labels that already exist.
We might want to use Kanban boards / lanes (or GitLab tasks) rather than:
- ticket queries embedded in wiki pages
Not sure how we are going to do this. It may depend on the wiki page and what is its purpose. Some of them may be converted into a board. Some of them may still exist and link to a query.
- CI tags
Labels can be used for this.
- sponsors?
Labels
- releases?
Milestones
- parent / child tickets?
Ticket ID process changes In Trac, people can use a ticket ID to find a ticket. In GitLab, each project can create *new* tickets with the same ID as tickets in other projects. (Even if we block all Trac ticket numbers, new tickets won't be blocked.) What processes will we need to change, now that ticket IDs need a project?
- ChangeLog / ReleaseNotes: ok, project can be determined from context
- ticket bot: needs project prefix
- can implement search order for non-prefixed numbers: legacy, tor, …
- any other contexts?
This was part of the conversation today (look at the notes). Mostly we will have to reference to to a specific project for a ticket. project#NNN instead of #NNN
Migration - existing projects If a project is already set up in GitLab, what do we do with Trac / GitLab ticket number conflicts?
Projects will get removed and recreated with the import. Trac is still the source of all truth for tickets. We will check for projects that may have been udpating gitlab and not trac.
The idea now is to keep numbers from trac and start new issues in gitlab after a specific number.
Proposal: each project consists of (GitLab tickets before migration)(blocked ticket numbers)(migrated tickets)(new tickets) Proposal: we create a new project for each transferred project, block the Trac ticket numbers out, transfer the legacy tickets, transfer the test project ticket, start opening new tickets
Yes. Something like this. Please look at the notes.
Keyword search Copied from the network team pad: When a field migrates to a keyword, is there a good way to search for tickets lacking any keyword corresponding to that field? gaba: yes. you can filter by issues that do not have a labels (so for example if sponsors are keywords, how do we search for issues with no sponsor keyword? Do we have to list every sponsor keyword?) gaba: there is a value 'None' https://dip.torproject.org/torproject/core/tor/-/boards?scope=all&utf8=%...
New questions: But what if the ticket has *some other* keywords, but no sponsor keyword? We'd need a regex like trac's !~=sponsor It looks like -sponsor or -sponsor* should do what we want, but we should check: https://docs.gitlab.com/ee/user/search/advanced_search_syntax.html
Yes
Suggested data migration / test details
Blockers
- If these fields aren't transferred as specified, we must roll back.
Ticket number Summary Description Comments (commenter, comment text) Milestone Keywords Actual Points Points Sponsor Component Reviewer
Important
- If these fields aren't transferred as specified, they should be fixed as soon as possible.
Type Version Reporter Parent ID - how does Parent ID get transferred?
Optional
- It doesn't matter if these fields are transferred or not.
- We probably can't transfer these fields in a useful way
Cc Priority Severity Trac magic links to ticket IDs and wiki pages
We are planning to migrate all info from tickets.
T
tor-project@lists.torproject.org
-
Damian Johnson -
gaba -
Gaba -
Hans-Christoph Steiner -
teor