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] Wise JIRA processing
Date Thu, 14 Dec 2006 14:10:32 GMT
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
View raw message