river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Hurley <Jim.Hur...@Sun.COM>
Subject Re: Draft Proposal - River basic dev process
Date Thu, 06 Sep 2007 20:31:30 GMT
On Sep 6, 2007, at 5:43 AM, Mark Brouwer wrote:
:
>> :
>> * Tracking issues and changes
>>      A JIRA issue is required for any substantive change.
>>      JIRA issues are not needed for small (e.g., typos) changes.
>
> Maybe it is good to state that controversial issues are expected to be
> discussed on river-dev before entering them in JIRA (to prevent from
> having loads of discussions on the issue that pollutes JIRA much).
>
> Also we might *encourage* users to discuss their 'demand' an river- 
> user
> before entering them in JIRA. Ever seen those open source projects  
> with
> thousands of open issue where it is almost impossible to get through,
> therefore some 'filtering' might not hurt, at least it makes you less
> depressed when looking for open issues.

Good points, all.  Thanks.  I'll update this section.

>> * Issue discussions
>>      Discussion on issues should occur via the Comments facility
>>      in JIRA.  This copies the river-dev list for the entire River  
>> dev
>>      community to see. River-dev email thread discussions on an
>>      issue are not prohibited (but not preferred), and if they occur
>>      than a summary must be posted back on the JIRA issue.
>
> JIRA will send reports to river-commit and not river-dev (the reply-to
> is set to river-dev though) so that means a lot of these 'discussions'
> won't be seen by some people (number of subscribers on river-commit is
> much lower than on river-dev).
>
> To me 'discussion' represents 'consideration of a question in open and
> usually informal debate' and I don't find JIRA a proper tool for that.
> It doesn't allow you to save your thoughts to draft and it has no
> threading. Therefore as a discussion forum it ranks low and IMHO
> pollutes the issue as in open discussions a lot of garbage is  
> mentioned
> (in hindsight).
>
> I find it good if it is used for comments for example how people have
> added comments to https://issues.apache.org/jira/browse/RIVER-6 .  
> But I
> hope we don't have to do the complete discussion e.g. whether we  
> should
> include Jetty in River as part of JIRA.
>
> I realize you mentioned "River-dev email thread discussions on an  
> issue
> are not prohibited (but not preferred)" and to me it should be the  
> other
> way around as long as you include a trace from a JIRA issue to the
> discussion.

I'm open on this one -- the option you're proposing will require that
a summary of the discussion (and pointer to the email thread) be placed
back into the JIRA issue for future tracking.

Would like other opinions on this one (to determine what the general
sense of the River Community is and to whether we should change the
Proposal).  What do *you* think?

>> * Code Reviews
>>      - for public API changes:
>>             RTC <http://apache.org/foundation/ 
>> glossary.html#ReviewThenCommit>
>>             These changes have potentially broad effects on  
>> developers
>>             and users, and therefore will require a code review  
>> and vote.
>>             Since some of these changes will effect the API docs  
>> ('specs'),
>>             everyone within the Jini/River community is encouraged  
>> to review
>>             and vote.  The PPMC member votes are binding, but the  
>> sentiment
>>             of the entire Jini/River community will certainly be  
>> strongly considered.
>
> Agreed.
>
>>      - for all other changes:
>>             CTR <http://apache.org/foundation/ 
>> glossary.html#CommitThenReview>
>>             Although CTR is what's specified, developers should feel
>>             comfortable requesting the list for peer review before  
>> committing.
>
> I'm not that fond of the above given the fact that many committers  
> have
> expressed they like RTC. The statement "although CTR is what's
> specified, developers should feel comfortable requesting the list for
> peer review before committing" doesn't feel to me (as a non-native
> speaker of the English language) as a real encouragement to ask for  
> peer
> review.
>
> As strong RTC is likely not going to work for reasons expressed  
> here (3
> serious +1's based on review is hard to get) I would at least like to
> see something along the lines Jukka mentioned: "a relaxed version  
> of RTC
> where Jira issues are raised for all non-trivial changes and a  
> patch or
> at least a written outline of the proposed solution is posted before
> making the change based on lazy consensus. This is actually what many
> (most?) Apache projects do in practice even if following the CTR  
> policy."
>
> Also I would rephrase in a way that peer review is kind of expected or
> the norm, this makes it clear for committers that they are expected to
> perform review code of others and as such it feels easier to do an  
> open
> outcry for a peer reviewer.

I was trying to lean in the direction I thought we were being led by our
mentors...   for example:
______________________________________________________
       From: Craig L Russell <Craig.Russell@Sun.COM>
       Date: August 30, 2007 5:31:24 PM EDT

       FYI...

      Thanks to this question, I've asked around and it looks like  
very few projects
      use the RTC model, and those projects use CTR for the trunk and  
RTC for
      backports where stability is paramount.

      Having RTC for some portions of a project where it's important,  
and CTR for
      other parts is a rational policy. Especially since RTC by the  
formal definition
      requires a +3 vote for all code changes, which is a pretty  
significant hurdle.
______________________________________________________

I also agree with Jukka's statement that "This is actually what many  
(most?)
Apache project do in practice even if following the CTR policy."    
Essentially,
I think we should specify CTR for these changes, but if the majority of
committers (which seems to be the case) feel like it's valuable to  
post a
proposed solution and/or have code review(s) done on a change in  
practice,
that's cool.  It's their (committer) choice based on their comfort  
level and
assessment of the changes. I think it's okay to trust the committers  
and only
require CTR for these changes.

I'd like to hear from others on this one as well.

thanks much -Jim




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