harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Beliaev <vladimir.k.beli...@gmail.com>
Subject Re: [general] Wise JIRA processing
Date Thu, 14 Dec 2006 14:36:07 GMT
Alexey,

please read carefully e-mail you are responding on.

 > 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