On Aug 25, 2006, at 12:48 PM, Guillaume Nodet wrote:
On 8/24/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I think David's comments on geronimo dev are spot on.
Begin forwarded message:
> More thoughts on the "where" and "how" topic.
>
> So far my thoughts on "how"; review to your satisfact
On 8/24/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
I think David's comments on geronimo dev are spot on.
Begin forwarded message:
> More thoughts on the "where" and "how" topic.
>
> So far my thoughts on "how"; review to your satisfaction and +1, 72
> hour cut off.
>
> As far as "where" ...
Any comments? Should I let this go?
-dain
On Aug 24, 2006, at 9:45 AM, Dain Sundstrom wrote:
I think David's comments on geronimo dev are spot on.
Begin forwarded message:
More thoughts on the "where" and "how" topic.
So far my thoughts on "how"; review to your satisfaction and +1,
72 h
I think David's comments on geronimo dev are spot on.
Begin forwarded message:
More thoughts on the "where" and "how" topic.
So far my thoughts on "how"; review to your satisfaction and +1, 72
hour cut off.
As far as "where"
I'm inclined to say "at your discretion" where the followin
Dain Sundstrom wrote:
On Aug 23, 2006, at 5:24 PM, Guillaume Nodet wrote:
Is a subproject entitled to make such decisions ?
Sorry, I didn't mean to imply we were able to make such decisions, but
we can make a recommendation to the PMC that they allow xbean to
operate under a different set o
On Aug 23, 2006, at 5:24 PM, Guillaume Nodet wrote:
Is a subproject entitled to make such decisions ?
Sorry, I didn't mean to imply we were able to make such decisions,
but we can make a recommendation to the PMC that they allow xbean to
operate under a different set of policies.
-dain
Is a subproject entitled to make such decisions ?
Anyway, I'm all in favor for a relaxed RTC, i.e. one
should send a mail to the dev list annoucing what he is doing
when working on big changes / new features.
Lazy consensus seems the right thing for xbean to me.
For example, I guess that my last
Geronimo is considering a change to its review and commit policies.
As a subproject, I think we should discuss how we would like to
handle reviewing code and when it should be committed. So...
How do you think we should handle this process?
What rules-of-thumb should we use to guide ourselv