harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [general] JIRA issue search problem
Date Mon, 18 Dec 2006 08:08:06 GMT
18 Dec 2006 14:01:27 +0600, Egor Pasko <egor.pasko@gmail.com>:
> On the 0x240 day of Apache Harmony Alexey Petrenko wrote:
> > Salikh,
> >
> > 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.
>
> That can be partially solved by pressing the "watch it" button for the
> issue you want to track. You will get the notifications on all the
> changes of watched issues by email. I use it regularly and it helps.
>
> If you had a good mail client that could filter email messages by the
> "[Patch Available]" substring in email _contents_, then you could
> easily get notifications of patch availibility for issues you are
> interested in.
I did not get your idea.
I'm interested to find free-to-fix issue. This means issue: 1. nobody
works on it, 2. It has no patch.
How "watch it" option will help in this?


> IMHO, this is good that only authors and comitters can set the "Patch
> Available" status. It induces a certain level of responsibility for
> JIRA owners to track the issues, review the patches, try them and
> respond.
Yes, I also like this approach more...
But from the other hand we can try free "patch available" setting to
see how it will work.

SY, Alexey

>
> > 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.
> >
> > 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, 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
> > >
> > >
> >
>
> --
> Egor Pasko
>
>

Mime
View raw message