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:49:57 GMT
2006/12/14, Vladimir Beliaev <vladimir.k.beliaev@gmail.com>:
> Alexey,
>
> please read carefully e-mail you are responding on.
OK, sorry :)

Please read carefully the thread you are responding on :)
Misha suggests some solution for 30-40% of contributors. And, I
believe, introduces some search problems for committers.
So it does not solve the problem.

SY, Alexey

>  > so you suggest to give full JIRA access to everybody
> I do not suggest a solution (this time, unfortunately). I claims one
> can't get information from JIRA effectively (I gave two example to
> explain) which
> - may cause people to do not participate in project
> - may produce information mess in JIRA
>
>  >> 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.
>
> Please read carefully. Your text is exactly the thing I wrote in second
> example:
>  >> AFAIK the way of "getting" JIRA is to write "I take
>  >> it" in its comment.
>
> And [1] does NOT (emotion!) explain what way can I find a JIRA to work
> on. And my two examples are about this issue.
>
> Basically my e-mail is about:
> - "JIRA handling process" should be improved asap - the number of bugs
> grows.
> - and we my think of accepting Mikhail's proposal until we have better one.
>
> Thanks
> Vladimir
>
> Alexey Petrenko 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
View raw message