river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: Draft Proposal - River basic dev process
Date Thu, 06 Sep 2007 09:43:49 GMT
Thanks Jim for crafting up a proposal, you are not going to make me have
to change the Board report before the 12th do you? ;-)

Below you'll find my first remarks, I tried to keep it short but I
failed utterly, sorry for that, I'll (try to) back-off from follow-ups

Jim Hurley wrote:
> I tried my best to weave an acceptable path through all the
> different options and opinions stated in the thread.  It's quite
> likely I didn't nail it the first time - so before calling for any vote
> on this Proposal, I'd like to discuss any major problems (or need
> for clarification) that people see.
> Just a comment as well - as has been stated... we don't have to
> get it perfect.  I'm sure whatever we agree to start with will evolve,
> as we gain experience with it, to something that will work best
> for us over time.  Let's get an acceptable starting place and
> move on.
> thanks -Jim
> -------------------------------------------------------------------------------------

> -------------------------------------------------------------------------------------

>               Apache River - Basic Development Process
> * 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.

> * 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

> * 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.


>      - 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

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.

BTW the website which is also in SVN could be subject to CTR except for
the parts that represent guidelines.

> * Testing
>       Developing test cases and running test suites are not
>       required prior to an integration.  If unit tests are created
>       for a change, the developer is encouraged to add them to
>       the JIRA issue for sharing.


> * Handling security -related issues
>       Enable a special field in JIRA to mark an issue as a security issue
>       and restrict  access to the JIRA issue to the PPMC and committers.
>       Hold initial discussions on potential security issues on the private
>       PPMC list.  When acknowledged that it's an valid security issue,
>       create a JIRA issue with special security field marked.
>       As soon as appropriate (for example, when the impact is understood
>       and/or there is a resolution and fix developed), open the issue and
>       discussion to the river-dev list.

Agreed, but does this also mean the exploit (which might be exactly
described in the JIRA issue) has to become publicly visible (river-dev
is public) before a patch release has been made available? I wonder how
that is handled by those 'Security Advisories' in general.

View raw message