serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <>
Subject Re: [serf-dev] Google Code Issue migration
Date Fri, 28 Aug 2015 20:59:17 GMT
On 28 August 2015 at 23:17, Lieven Govaerts <> wrote:
> On Fri, Aug 28, 2015 at 7:11 PM, Ivan Zhakov <> wrote:
>> On 27 August 2015 at 23:22, Ivan Zhakov <> wrote:
>>> On 27 August 2015 at 22:52, Lieven Govaerts <> wrote:
>>>> On Wed, Aug 26, 2015 at 8:52 PM, Ivan Zhakov <> wrote:
>>>>> Status update:
>>>>> ASF INFRA team performed test import for us:
>>>>> The following data was converted:
>>>>> 1. Summary
>>>>> 2. Reporter and current assignee
>>>>> 3. Comments with original date and author
>>>>> 4. Labels
>>>>> 5. Issue status and resolution
>>>> Looks good.
>>> Cool!
>> [...]
>>> I've asked INFRA team to perform another migration for us with
>>> improved import data. I hope it will be final import.
>> INFRA team completed another migration for us and I'm inclined to
>> consider it as final:
>> I think that current state is good enough. May be something could be
>> improved, but it doesn't worth the efforts.  Opinions?
> Looks fine by me Ivan, great work!

> Will serf committers get a special role in the project in Jira? Or
> does anyone with an account can do everything?
Typical setup is the following [1]:
Q: How do permissions work in JIRA?

A: Projects are mapped to a single permission scheme (multiple
projects may share a permission scheme). There are users and groups
(no nested groups). A permission scheme lists possible actions (view
issues, create issues, assign issue, schedule issue, delete issue,
etc...) to one or more users or groups. For the ASF JIRA install, each
ASF project gets one JIRA project per releasable product (so you can
release version 1.6 of tool X and 1.3 of tool Y). Typically we create
one permission scheme for all those products. Typically we also create
one group for that permission scheme. Standard permissions are as

public can browse project (view issues), create issues, add comments,
link issues, and create attachments. issue reporter can edit an issue
project group (your developers/committers) can also edit issues,
schedule issues, move issues, assign issues, be assigned issues,
resolve issues, close issues, manage releases, and manage components.
one or two people also get added to "JIRA administrators", which is
system-wide access to let you manage who is in your group. Projects
are always free to suggest alternate plans.


Ivan Zhakov

View raw message