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 Fri, 15 Dec 2006 09:34:31 GMT
Geir,

thanks for commenting on my examples.

As far as I understand, you consider the dev-list as the primary source 
of project information (because community keeps this information and 
pass downs it through dev-list).

I do not argue, still it seems then (to me) that a contributor must not 
inspect through JIRAs at all. Community (through dev-list) just propose 
a contributor to work on <this> issue (which may be described in JIRA or 
  in one of e-mail thread in dev-list or in Wiki page). The final patch 
can be posted to dev-list also - no need to attach it to JIRA.

This is the way I understand your comment. So, I see no value in JIRA at 
all... Say, I see the bug in JIRA, but this bug may be obsoleted because 
"community have a re-design of the threading system in progress".

If all the above is true, then why do not we just "hide" the JIRA at all 
to avoid later confusions?

Again, I do not argue, I'm trying to understand...

I believe, 1 source of information is the way to avoid ambiguity:
- if it is dev-list, then ok - let get rid of JIRA at all and do not 
promote it to contributors (or may it visible to committers only or 
whatever)
- if it is JIRA (as list of stuff to work on) then let's improve JIRA. 
Answering your examples, I would say, that "JIRA contributor" may go 
through all JIRAs and change the priority of JIRAs according to current 
goals of community. Of he/she may go through JIRAs and comment on some 
of them with "going to be irrelevant ...".

Thanks
Vladimir

Geir Magnusson Jr. wrote:
> 
> 
> 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...
> 
> Yeah, I think that's where I stand here.  I think that the dev list is 
> the place where you can count on activity happening in the project.
> 
>>
>> 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...
> 
> Right - and if you sent a note to the dev list and said "hey!  I'm a 
> threading expert!  What would be useful for me to work on?" you'd
> 
> a) make people aware of you and your skills
> 
> b) be able to contribute where the existing community wants to see work 
> done
> 
> With b), people always have the freedom to work on what they want and 
> don't need to ask, but I think it's far more productive to talk with the 
> rest of the people worried about an area you want to work on and start 
> there.
> 
> 
>>
>> 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.
> 
> I don't think that is the right way to figure it out.  Why would you 
> think you can get a good understanding of the history and future plans 
> for threading by reading through a set of JIRAs?
> 
> The existing community is able to provide context and intent.  The 
> community might have a re-design of the threading system in progress, 
> and those bugs you are about to work on are about to be irrelevant...
> 
> geir
> 
> 
>>
>> 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