harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [general] Wise JIRA processing
Date Fri, 15 Dec 2006 16:35:52 GMT
I'm not Geir, but I will comment too

Vladimir Beliaev wrote:
> As far as I understand, you consider the dev-list as the primary source
> of project information (because community keeps this information and
> pass downs it through dev-list).

Primary source of information is community (i.e. people), and
dev-list is the easiest way to get in touch with those people.

> I do not argue, still it seems then (to me) that a contributor must not
> inspect through JIRAs at all.

I disagree.
Working with issues without looking into details is highly likely to become
sort of bureaucracy (seen it to much in work experience).
If contributor is not interested in inspecting JIRAs details,
then s/he is not interested in JIRA issues at all.

> Community (through dev-list) just propose
> a contributor to work on <this> issue (which may be described in JIRA or
>  in one of e-mail thread in dev-list or in Wiki page). The final patch
> can be posted to dev-list also - no need to attach it to JIRA.

This work style exists in other open-source projects (most notably, Linux
kernel). However, Geir and Tim insisted on using JIRA, explaining that it is
easier to control code provenance this way.

> This is the way I understand your comment. So, I see no value in JIRA at
> all... 

JIRA has high archival value in explaining past SVN commits. Most of the
commit messages do not have full information on the change, but rather
the link to a JIRA issue.

I consider this a *primary* value of JIRA.

> Say, I see the bug in JIRA, but this bug may be obsoleted because
> "community have a re-design of the threading system in progress".

Yes, this is possible. However, it is equally possible that you fix
the problem faster and better than the other person who started working
on issue earlier. In any case, you would want to communicate with other
engineers interested in the problem, discuss the approaches and choose
the best solution.

> I believe, 1 source of information is the way to avoid ambiguity:
> - if it is dev-list, then ok - let get rid of JIRA at all and do not
> promote it to contributors (or may it visible to committers only or
> whatever)

No. We need JIRA to track patch origin (i.e. who is the original author),
and to keep detailed information about changes (i.e. why the change was
committed). Neither of this can be addressed on the mailing list.

> - if it is JIRA (as list of stuff to work on) then let's improve JIRA.
> Answering your examples, I would say, that "JIRA contributor" may go
> through all JIRAs and change the priority of JIRAs according to current
> goals of community. Of he/she may go through JIRAs and comment on some
> of them with "going to be irrelevant ...".

If the person is interested in Harmony project enough to go through JIRA
and make sure no issues are left unaddressed, then IMHO s/he deserves
committer status.

It looks like we can get away without introducing new role.


Mime
View raw message