harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [general] Wise JIRA processing
Date Thu, 14 Dec 2006 15:15:40 GMT
Guys,

My understanding: I agree that contributors' "rights and freedoms" is
a valuable thing, but JIRA also needs to address security and
role-separation issues that brings discomfort to contributors by its
definition. So the most "comfortable" solution would be to give a
committer status to everyone. But since such solution is not
acceptable it is necessary to define some compromise. IMO JIRA +
Apache policies is a good compromise that fits the situation.

In another words. IMHO the true open source contributor should be
persistent while searching for the place where to contribute and
patient while waiting for his/her JIRAs to be applied.  :-)

Thanks,

2006/12/14, Vladimir Beliaev <vladimir.k.beliaev@gmail.com>:
> 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



-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message