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 <[EMAIL PROTECTED]>
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
