harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [general] JIRA issue search problem
Date Sat, 16 Dec 2006 07:06:32 GMT
Let's make things simple.
What a contributor needs is just another field to mark who is working
on the issue. Imaging that these is a link on the issues page, the
field will be set to my name if I click the link and will be set to
*nobody* if I click again. Any contributor is able to see the link
only if the field is *nobody* or himself.

BTW, the Patch Available should be able to set by everyone.

On 12/16/06, Zakharov, Vasily M <vasily.m.zakharov@intel.com> wrote:
>
> And here's my contributor +1 to Alexey's point.
>
> Searching and sorting for "right" JIRAs to pay attention to
> is a routine, permanent task. Let's make it easier.
>
> For now, I am forced to have a separate table on my computer
> with the list of JIRAs I'm interested in and with additional
> status marks. And I'd like to get rid of it. :)
>
> With best regards,
>  Vasily
>
>
> -----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
>
> 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.
>
> 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
> >
> >
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message