harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [general] JIRA issue search problem
Date Fri, 15 Dec 2006 16:11:39 GMT
+1 to all that Salikh just has said.


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

Alexei Zakharov,
Intel ESSD

View raw message