Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Salikh Zakirov <Salikh.Zakirov@Intel.com>
Subject: Re: [general] JIRA issue search problem
Date: Fri, 15 Dec 2006 18:55:44 +0300
Lines: 77
Message-ID: <elugi0$nul$1@sea.gmane.org>
References: <c3755b3a0612140713r4cb12a3q1de7b0dd42bbe6f6@mail.gmail.com>
	 <2c9597b90612140730h2ce205aeq6ab8a622167506d5@mail.gmail.com>
	 <c3755b3a0612140846l4f47e19bu97ed8580a674ce3d@mail.gmail.com>
	 <4581B959.2000100@pobox.com>
	 <c3755b3a0612142338g9fda78dqaa4b31cfdf5e5b01@mail.gmail.com>
 <51abf0750612150451s45f9aebdx7050299d0945cabe@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
In-Reply-To: <51abf0750612150451s45f9aebdx7050299d0945cabe@mail.gmail.com>
Sender: news <news@sea.gmane.org>

Original problem statement was formulated by Mikhail:
> For example, if the JIRA is not assigned then there is no simple way to
> understand if there's activity in there except opening it in web-browser and
> reading comments.

I would argue that anyone who is really going to work on an issue, will
definitely want to read through issue comments carefully, so this is not
a problem for contributors.

Rather, this is a problem of managers of employees assigned to work
on the Harmony project, as they (managers) do not have good means to monitor
what issues engineers work on.

> Only committers could modify the status of JIRAs and put them "In progress"
> mode. As we have not so many committers they could not monitor large number
> of open JIRA.

>From the point of view of open-source community (set aside corporate culture
etc.), there is no difference between "unassigned" and "in progress" issue,
as this basically means that the fix is still not available.

And if anyone _really_ interested in fixing a problem, then reading comments
and interacting with others interested in the same problem is *good*.
It facilitates better patch and design review, and overall leads to a better
software quality.

However, several engineers working on the same problem is perceived as
an inefficiency in corporate setting, and thus is stated as a problem.

Thus, the second problem is also induced by _sponsoring corporations_.

In short, both Harmony contributors and committers (with "Harmony hat on") have
*none* of the stated above problems.
It is managers of sponsoring corporations that need improvement in JIRA
searching capabilities.

I am not suggesting that Harmony should ignore wishes of the managers
of sponsoring corporations, but I think that the problem could be solved
much better if the problem and its justification is stated clearly,
without alluding to contributor problems which do not really exist.


But then, with current JIRA configurations, some problems do exist,
which could be addressed tweaking JIRA configuration, but now requires
mail communication. This is something that I encountered in *my practice*:

* When submitting a patch for an issue filed by someone else, the committer
attention will not be attracted automatically, because I can't set 'patch
available' status. The workaround for this is to create subtask for the
fixed issue, and attach patch to that subtask, with 'patch available' set.
IMHO, this workaround is good enough.

* When searching for issues related to particular component, I can easily
miss some of them, because '[component]' notation is not universally used
(now and then someone forgets to add component), and since only committers
and submitters are allowed to edit jira summary and categories, cleaning
up issues requires mail communications.

IMHO, None of this is critical, and may be left as is.

> How about the following structure:
> 1) Contributor assignee field for everybody (if a committer working on
> patch preparation he/she should use this field). Also, for example, if it's
> non-null then the status of unresolved JIRA is "In progress" automatically.
> 2) Committer assignee field for committers

These are not really needed neither to committers, nor to contributors.
It will not do any harm though, and definitely will be useful
for sponsoring corporations.

So, +0

> 3) Everybody could set "Patch available" tag (another option is: JIRA
> contributor assignee, JIRA author or committers coud set this tag)

This will make submitting patches easier for contributors.
+1