harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm][threading] a question about JIRA H3253
Date Wed, 07 Mar 2007 16:09:12 GMT
OK, it's just a thought.
Some of the JIRA comments are excellent and focussed actually. Somehow most
concerned parties seem to find their way there :-)


On 3/7/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
> On Mar 6, 2007, at 10:52 AM, Rana Dasgupta wrote:
>
> > My thought was that if we have a JIRA related "discussion" on the
> > list, the
> > intent is possibly to invite more comments, not just from the
> > submitter and
> > reviewer. If one feels that this broader participation or interest is
> > necessary, it may be a good idea for whoever posts it on the list
> > to add a
> > few words to provide some context and background on the problem, which
> > should not be hard to do. Otherwise, the discussion stays closed.
>
> But I think that we always want to invite broader participation and
> interest.  if people bite, great.  If they don't, no harm done.
>
> I actually engaged on weldons question, looking at what he was
> talking about.  I hate reading through JIRa comments :)
>
> geir
>
> >
> >
> >
> > On 3/6/07, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> >>
> >> Rana Dasgupta wrote:
> >> > IMHO we may be better off if we post brief discussions on
> >> > commits/reviews on
> >> > the JIRA, rather than on the list, unless it is an architectural
> >> issue
> >> or
> >> > one where several opinions could add value. There seem to be
> >> several
> >> > threads
> >> > where the entire thread consists of a single post and a
> >> response :-)
> >>
> >> Rana,
> >>
> >> there is nothing wrong in a single post and a response, because the
> >> purpose of
> >> harmony-dev posting is to discuss things *in public*, rather than
> >> having
> >> hot
> >> discussions all the time.
> >>
> >> Should Weldon posted his comment in JIRA, I would probably miss it.
> >>
> >> And, by the way, using locks *is* an architectural issue.
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message