harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Alexey A" <alexey.a.iva...@intel.com>
Subject RE: [general] JIRA issue search problem
Date Mon, 18 Dec 2006 08:05:39 GMT
>-----Original Message-----
>From: Alexey Petrenko [mailto:alexey.a.petrenko@gmail.com]
>Sent: Friday, December 15, 2006 8:44 PM
>To: dev@harmony.apache.org
>Subject: Re: [general] JIRA issue search problem
>there is some truth in your words...
>Yes, if we got a big issue then nothing strange in fixing it by 2, 3
>or 10 people. And fix will probably appear faster and will be better.
>But most of 700 open issues in JIRA now are rather simple issues. Like
>wrong exception,  no exception and so on. How many people will we need
>to add an NPE check? 2, 3 or 10? There is an old joke: "How many
>programmers do you need to change the lamp?" :)
>And it's real pain to open tens of simple issues to check if somebody
>already working on it. Impossibility of setting "patch available" flag
>makes the situation even worse because you should check already fixed
>issues too while you find some free to fix issue.

I completely agree. To allow setting "Patch Available" flag for
everybody will not make any harm, and will ease working with issues. We
can be optimistic here: a contributor provides a patch to fix the
problem described. Contributor makes sure their patch doesn't break any
tests, and sets the flag. The issue reporter may check if the patch
solves the problem. If it's OK, they may add a comment about it. It'll
be clear for everyone there's a solution to try. On the other hand, if
the reporter tested the patch and considers it is not good or doesn't
fix the issue, they simply clear the flag providing the explanation why.
The same way a committer can test the fix and update the issue. But if
"Patch Available" isn't set, it will take much more time until a
committer pays attention to a certain issue.

>So adding additional assignee field will help to sort the issues and
>will make life for all contributors easier. From the other hand it
>will not bring any troubles in fixing complicated issues by teams.
>Is it a problem of contributors or managers? I'm not a manger...
>yet... :) So I do not know is it important for them or not. I've never
>heard any questions from my manager about JIRA processing.
>Contributors? I'm, as a Harmony contributor, has a problem with
>searching issues. I've asked few Harmony contributors around and they
>supported my vision.
>So I would say that there is a problem for Harmony contributors and I
>know nothing about managers.

I tend to agree here too. If the problem seems to be easy from the
description, one can look at additional assignee field and see if
someone works on it. There'll be no need to open the issue and read
Additionally, if someone who started investigating the issue faces the
issue is not as easy as it seemed, they can always write a message to
the dev-list and ask for help.

This way, I think, having such a field will make finding and fixing easy
issues faster.

(If a manager wants to monitor their employees activity in JIRA, having
such a field will also make their life easier. But the main point is to
simplify life for contributors.)


>SY, Alexey
>2006/12/15, Salikh Zakirov <Salikh.Zakirov@intel.com>:
>> 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,
>> definitely want to read through issue comments carefully, so this is
>> 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
>> what issues engineers work on.
>> > Only committers could modify the status of JIRAs and put them "In
>> > mode. As we have not so many committers they could not monitor
>> > of open JIRA.
>> From the point of view of open-source community (set aside corporate
>> etc.), there is no difference between "unassigned" and "in progress"
>> as this basically means that the fix is still not available.
>> And if anyone _really_ interested in fixing a problem, then reading
>> and interacting with others interested in the same problem is *good*.
>> It facilitates better patch and design review, and overall leads to a
>> software quality.
>> However, several engineers working on the same problem is perceived
>> an inefficiency in corporate setting, and thus is stated as a
>> Thus, the second problem is also induced by _sponsoring
>> In short, both Harmony contributors and committers (with "Harmony hat
>> *none* of the stated above problems.
>> It is managers of sponsoring corporations that need improvement in
>> 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
>> 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
>> mail communication. This is something that I encountered in *my
>> * When submitting a patch for an issue filed by someone else, the
>> attention will not be attracted automatically, because I can't set
>> available' status. The workaround for this is to create subtask for
>> fixed issue, and attach patch to that subtask, with 'patch available'
>> IMHO, this workaround is good enough.
>> * When searching for issues related to particular component, I can
>> miss some of them, because '[component]' notation is not universally
>> (now and then someone forgets to add component), and since only
>> and submitters are allowed to edit jira summary and categories,
>> 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
>> > patch preparation he/she should use this field). Also, for example,
>> > non-null then the status of unresolved JIRA is "In progress"
>> > 2) Committer assignee field for committers
>> These are not really needed neither to committers, nor to
>> 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:
>> > contributor assignee, JIRA author or committers coud set this tag)
>> This will make submitting patches easier for contributors.
>> +1

Alexey A. Ivanov
Intel Enterprise Solutions Software Division

View raw message