> Whether it's strict or not-strict isn't uber important.
>
> At Apache, those doing the work decide. If those doing the work really want
> to take advantage of patch reviewing, before committing stuff to version
> control,
> by all means. I'm a big fan of Review Board, but I never like projects
> that
> *require* anything, least of all patch review. These are really community
> and
> social norms we're talking about here, not technical.
>
I read this as a pretty exact restatement (with more detail) of what I
said, so I don't think we're in disagreement here.



> If there is a desire by a minority to perhaps commit and not hold
> stuff in patches, and that minority has a ton of great work and thoughts,
> and discusses
> them on list, I would encourage Tajo to tell that minority (PPMC member,
> let's say):
>
> 1. Create a branch
> 2. Go wild
> 3. Merge into *pristine* area selectively, with consensus, (LOL I'm not a
> Git expert, but in my SVN mind, let's
> say "trunk") and that merge may need to be reviewed by patch review, if
> most of the Tajo peeps
> like RTC and are working in that pristine area.
>
> We're using version control here, and branches are cheap, so I would
> encourage the
> above flow. That being said, "play nice" is the advice I'd give :)
>
Yep, this is great for large amounts of work that require a higher velocity
than may otherwise be available.  It's effectively still RTC since that
final merge should be reviewed - even more so than a regular commit.  But
that's not what's being discussed here.  I don't see any work of that
magnitude imminent.


>
> Yeah I guess I'm ambivalent. I think people should be able to operate in
> both
> modes per my 1-3 above. I tend to do that in OODT, Nutch, Tika,
> Solr/Lucene (when
> I was on those projects), SIS, Gora, etc.


And for the projects I've done RTC has worked great.  Neither is right or
wrong.  It's like driving on the right or left - either works fine, but
everybody should know what the expectation is to avoid nasty collisions.
 RTC seems the more conservative, safer bet and has a large number of +1s
behind it.  And, of course, if the emerging community finds it cumbersome,
it should be jettisoned or re-evaluated.  I just want to make sure that no
hackles get raised in the beginning by unexpected commits showing up.

Reply via email to