harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Markov" <mikhail.a.mar...@gmail.com>
Subject Re: [general] Wise JIRA processing
Date Thu, 14 Dec 2006 15:11:55 GMT
Easy, guys :-).

There are 2 problems (possibly partially related to each other):
1) More effective searching in JIRA
2) More effective JIRA processing (changing status, assigning etc.)

Both should be solved. My initial message was about the 1-st one, but i
agree that 2-nd is also a problem - perhaps it makes sense to start a new
thread?

Regards,
Mikhail



On 12/14/06, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
>
> Vladimir,
>
> so you suggest to give full JIRA access to everybody. Otherwise your
> solution does not have any sense since it solves the "problem" for
> only 30-40% of contributors.
>
> > AFAIGot the existing solution here is: each contributor should write to
> > dev-list the question like "what is going on" and "what can I work on"?
> > If this is true, then you can skip later reading...
> No the existing solution here [1] is to write a comment to the JIRA
> issue that you are starting to work on it and that you are finished.
> And as we agreed with Misha grant everybody possibility to set "In
> progress" flag to everybody is a probably good idea.
>
> SY, Alexey
>
> [1] http://harmony.apache.org/issue_resolution_guideline.html
>
> 2006/12/14, Vladimir Beliaev <vladimir.k.beliaev@gmail.com>:
> > Hello,
> >
> > interesting point... I'm looking to JIRA from contributor prospective
> > and I can't get idea from it what is going on with bugs.
> >
> > AFAIGot the existing solution here is: each contributor should write to
> > dev-list the question like "what is going on" and "what can I work on"?
> > If this is true, then you can skip later reading...
> >
> > Let me explain:
> >
> > About "subcomponents": suppose, I'm VM threading expect (just suppose -
> > I'm not actually) and I want to join Harmony (as contributor). I'm
> > looking into JIRA and see ... h-m-m ... 148 issues... Ok, let's use
> > filtering - I use 'thread' in search pattern - wau, 105 issues found and
> > most of them has nothing to do with threading... I better do not look
> > through all 105 JIRAs and give up...
> >
> > About "assigments": suppose I got the list of thread related issues
> > (some way - say, we agreed to add [thread] suffix after [drlvm] prefix
> > and "JIRA ontributor" regularly re-checks all JIRAs to update summary
> > acordingly). The number of 'thread' JIRAs is pretty great (say 30). Non
> > of these issues is assigned (no committer has taken it). Ok, I want to
> > work on one of them. AFAIK the way of "getting" JIRA is to write "I take
> > it" in its comment. I start looking through JIRAs and finding "I take
> > it" in each of them before I find "non-taken" one at the end of list -
> > something to make any guy distracted.
> >
> > Base on above I believe we should do something with existing JIRAs -
> > probably Mikhail proposal (about "JIRA ontributor") is one which worth
> > implementing.
> >
> > Thanks
> > Vladimir
> >
> > Mikhail Markov wrote:
> > > Ok, i'll try to write the picture as i see it (perhaps too innovative
> :-)):
> > >
> > > General:
> > > There are currently (Apache standard) 2 roles: contributors &
> committers
> > > (contributors could open JIRA, assign patches, committers could modify
> > > JIRA(reopen, close etc.) and commit the code). People are gained
> committer
> > > status when they demonstrated significant dedication to the project
> etc.
> > > Roughly speaking, the distribution is 3% - committers, 97% -
> contributors
> > >
> > > The suggestion is to have 3 roles: contributors, "JIRA contributors"
> (or
> > > whatever...) & committers. JIRA contributors could modify JIRA. People
> are
> > > gained JIRA contibutor status also when they demonstrated significant
> > > dedication to the project, but less, or less significant :-).
> > > Some JIRA could be resolved without any commits to svn (not
> reproducible,
> > > for example), so JIRA contributors could resolve such issues.
> > > I think that having 30%-40% of people having full JIRA access will be
> > > enough.
> > >
> > > Why:
> > > If we think of development in a private company working on not too
> large
> > > project, then usually everybody have full access to bugtracking system
> so
> > > people could easily reassign/close etc bugs and at the same time
> people
> > > discuss technical details in the mailing list. Of course Harmony is
> open
> > > source, but we strive to become "world class, certified implementation
> of
> > > the Java Platform Standard Edition" we could utilize such experience
> for
> > > quicker JIRA processing. As there are usually a lot of JIRA, but
> little
> > > number of committers, whose primary role, imo, applying patches (if
> they
> > > don't do it, then who would? :-)), they might be busy with this
> activity
> > > and
> > > have no time for everything else, this adding new role could help
> quicker
> > > deal with issues which do not require committing. At the same time i
> do not
> > > think people will less talk and discuss in the mailing list.
> > >
> > > (Also particular answers inlined below.)
> > >
> > > Regards,
> > > Mikhail
> > >
> > >
> > > On 12/14/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >>
> > >>
> > >>
> > >> Mikhail Markov wrote:
> > >> > On 12/14/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >> Mikhail Markov wrote:
> > >> >> > HI!
> > >> >> >
> > >> >> >
> > >> >> > In my opinion, it's hard to track open JIRAs now.
> > >> >> >
> > >> >> >
> > >> >> > 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.
> > >> >> > 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.
> > >> >>
> > >> >> I'm not sure how your solution helps this.  Can you explain?
> > >> >
> > >> >
> > >> > Just plain statistics (for classlib):
> > >> > Open JIRA #: 425
> > >> > Assigned JIRA #: 52
> > >> > Reopened JIRA #: 6
> > >> > In progress JIRA #: 5
> > >> > It's not easy to answer the question: "are there any activity in
> other
> > >> open
> > >> > JIRA?"...
> > >> > The only indicator is "In progress" tag. Only committers could set
> this
> > >> > tag,
> > >> > but as the number of JIRA is rather large they could not monitor
> > >> > everything.
> > >> > The proposal is to increase the number of "JIRA masters".
> > >>
> > >> Does this really solve anything though?  To monitor the progress, you
> > >> have to open each JIRA anyway.
> > >
> > >
> > > To monitor progress - yes, to see is there any progress at all - no.
> > >
> > >
> > > The only thing that I think this solves (and please, correct me if I'm
> > >> wrong - I'm severely jetlagged and was up very late last night, so I
> may
> > >> not be thinking straight) is that instead of one of us marking a JIRA
> as
> > >> in progress when someone pops onto the dev list and says they want to
> > >> work on it (which gives much greater visibility to all of us), a
> > >> non-committer can do that themselves.
> > >>
> > >> Maybe I'm simply stupidly biased about this, but I still think that
> > >> driving people here to the dev list for engagement is the healthiest
> way
> > >> to go.
> > >>
> > >> That said, if you think there's a problem to solve here, lets either
> > >> convince me that I'm wrong, or find another solution - maybe as a
> group
> > >> think about better ways to track work like this?
> > >>
> > >>
> > >> >
> > >> >>
> > >> >> >
> > >> >> > One of possible solutions is implemented in Apache Geronimo
> project:
> > >> >> there
> > >> >> > is so called "JIRA contributor" role when the person could
> modify
> > >> JIRAs
> > >> >> > like
> > >> >> > committers (close/reopen JIRA, modify it's status etc.) but
> could
> > >> not
> > >> >> > commit
> > >> >> > the code to the repository.
> > >> >> >
> > >> >> > This role seems intermediate between contributor and committer
> ones,
> > >> >> some
> > >> >> > kind of "committer kindergarten" :-).
> > >> >> >
> > >> >> > I think that for better processing JIRA issues we could
> implement
> > >> >> similar
> > >> >> > role in Harmony (or invent something better).
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > What do you think?
> > >> >> >
> > >> >>
> > >> >> I'm not a fan.  I want to ensure that people show up here on the
> dev
> > >> >> list, interact with others, and simply *engage*.  While I haven't
> > >> looked
> > >> >> closely in the last week, my personal impression of things is
that
> we
> > >> >> already have quite a bit of "conversation" on JIRA that never
is
> > >> visible
> > >> >> on the dev list, which isn't very good, IMO.
> > >> >
> > >> >
> > >> > I don't think that every problem should be discussed in dev list.
> For
> > >> > simple
> > >> > cases it's enough to talk in JIRA, but weird cases of course should
> be
> > >> > discussed in the list and after the discussion the decision should
> be
> > >> > reflected/implemented in the JIRA.
> > >>
> > >> I guess I don't agree, but in a very particular way - I don't think
> that
> > >> every problem needs to be discussed, but I think that if a problem
> needs
> > >> discussion, it should be on the dev list.
> > >
> > >
> > > I have different opinion :-) - JIRA is not only issues/bugs processing
> > > thing, but also a natural way of discussing particular problems, which
> may
> > > be not too interesting for a wide community.
> > >
> > >
> > >> And in my opinion this is what happened today so i don't see any harm
> > >> > adding
> > >> > new roles - this will just help JIRA putting (and having it after
> that)
> > >> in
> > >> > order.
> > >>
> > >> Which JIRA or issue?
> > >
> > >
> > > Recent example: http://issues.apache.org/jira/browse/HARMONY-2383(should
> > > be "In progress" i think).
> > >
> > >
> > > geir
> > >>
> > >> >
> > >> > Regards,
> > >> > Mikhail
> > >> >
> > >> > So I guess I'd probably need to understand better what this does
> for
> > >> us,
> > >> >> and why it wouldn't have those negative community effects.
> > >> >>
> > >> >> geir
> > >> >>
> > >> >
> > >>
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message