harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] Wise JIRA processing
Date Fri, 15 Dec 2006 08:30:27 GMT
On the 0x23F day of Apache Harmony Vladimir Beliaev wrote:
> 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...

In that case, I would have written to the mailing list: "hello, guys,
I am a VM threading expert, what are the hottest tasks for me?" We
have 1 threading item in the "Core VM Development tasks" that I can
find.

Quite simple and fast.

> 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
> >> >>
> >> >
> >>
> >
> 
> 

-- 
Egor Pasko


Mime
View raw message