Re: Re: Returning to Commit-Then-Review?

[Jason Dillon <ja...@planet57.com>]

I will support anything that does not leave patches to fester and
still provides any required pre-commit oversight.

I would really like to see a CTR-like policy that puts trust back into
the community for example, I trust Hirams activemq patch but my
concurrent patch... well I want others to ack it first, as it his
areas of the server which are not as familiar to me.

It seems to me that David's proposal fits into this...

Can we please make an effort to agree on a policy?  And once agreed
upon, have the PMC officially announce it?

I believe this is critical for our community to move forward.

--jason


On 8/25/06, David Blevins <da...@visi.com> wrote:
> So anyone have any thoughts on this?  I'll assume there's no support
> unless I hear otherwise.
>
> -David
>
> On Aug 23, 2006, at 1:14 PM, David Blevins wrote:
>
> > On Aug 22, 2006, at 6:56 PM, David Blevins wrote:
> >
> >> I'd be more inclined to talk about what we want to apply it to and
> >> how.
> >
> > 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 following are
> > encouraged:
> >  - Significant new functionality
> >  - Significant changes
> >  - Patches from Contributors
> >  - Borderline "fixes" to a stable branch
> >
> > Whether or not it merits RTC would be at your discretion.  It is to
> > your advantage in these situations because:
> >
> > - "Significant new functionality" and "Significant changes": It's a
> >    "Get out of jail free" card.  Having more people understand your
> >    code keeps you from spending all day on the user list.  You do
> >    support your code on the user list, right?
> >
> > - "Patches from Contributors": Getting three votes for your patches
> >    is not a bad way to, in time, get your three votes to be a
> >    committer.  Let's be clear, someone who commits all your patches
> >    with no review from others on the project isn't doing you any
> >    favors.  It's in your interest to push to get your votes on every
> >    patch.
> >
> > - "Borderline 'fixes' to a stable branch": It's a given you will
> >    think everything you want to put in a stable branch is important.
> >    But, is it a fix or is it a new feature?  If you think others may
> >    disagree, you may want to put it up for review or you may find
> >    yourself running the TCK all alone with no help.
> >
> >
> > Those are the advantages you stand to gain should you choose to use
> > RTC for any of the above situations.  RTC is not the only way to
> > get the above benefits, so it is at your discretion whether or not
> > your situation merits it.
> >
> > My pragmatic take on RTC for the moment.
> >
> > -David
> >
>
>

Re: Re: Returning to Commit-Then-Review?

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 9/6/06, Jason Dillon <ja...@planet57.com> wrote:
> I will support anything that does not leave patches to fester and
> still provides any required pre-commit oversight.
>
> I would really like to see a CTR-like policy that puts trust back into
> the community for example, I trust Hirams activemq patch but my
> concurrent patch... well I want others to ack it first, as it his
> areas of the server which are not as familiar to me.
>
> It seems to me that David's proposal fits into this...
>
> Can we please make an effort to agree on a policy?  And once agreed
> upon, have the PMC officially announce it?
>
> I believe this is critical for our community to move forward.

Thanks Jason for bringing it up. I started a page
http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=23530
to let us know where we are. Nothing there yet, but let us^H^Hme get
started. Will copy emails from Dave and others there.

It's accessible from
http://cwiki.apache.org/confluence/display/GMOxPMGT/Documentation, but
it doesn't look good.

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl