[tor-project] reminder meeting (Re: Follow up Gitlab next steps (Re: update on ticket system discussion)
teor
teor at riseup.net
Tue Sep 17 08:13:31 UTC 2019
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=%E2%9C%93&state=opened&label_name[]=None
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
--
teor
----------------------------------------------------------------------
> On 17 Sep 2019, at 02:48, Gaba <gaba at torproject.org> wrote:
>
> 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:
>>> 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-OADl4YRMTiRB0G9DHvj23NRpwzcc/edit#gid=0
>>> [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/Notes/InternalTooling
>>> [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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20190917/92984858/attachment-0001.html>
More information about the tor-project
mailing list