GSoC2007 work

[Mark Grimes]

On 6/4/2007, "Jordan K. Hubbard" <jkh at brierdr.com> wrote:
>
>On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote:
>
>> 	Again, many reasons to move GSoC work to branches and very little
>> to have it happen right on trunk, in my opinion. I'll make the move
>> if no one presents a case against it, so please speak up if you feel
>> you have valid arguments against moving to branches. Thanks!
>
>I object.  I'm completely in agreement with James - the SoC
>contributors shouldn't be treated any differently than other
>contributors (lest we create 2nd class citizens in what is otherwise
>supposed to be an open project, regardless of how someone gets
>here).   A branch also isn't a quarantine mechanism to be arbitrarily
>placed on a contributor* - it's an organizational tool to be used in
>certain situations which depend ENTIRELY on the types of changes in
>question.   That should be left to the discretion of the contributor.
>
>Artificially constraining things to branches is also generally the
>first step in ensuring their decay and eventual death.  That's a
>fairly strong argument against.
>
>- Jordan
>
>* Yes, I'm also familiar with the "untrustworthy contributor"
>scenario, but the solution there still isn't a branch, it's a
>committer proxy.)

Subversion does not currently support merge tracking (without svk), so
this makes cherry picking a micromanagement burden and probably weighs
in somewhat on the branching stigma as well.  Only rudimentary support
is targeted for Subversion 1.5, but presumably more robust by 1.6, so
additionally I don't think this (merging branches back to trunk)
aversion will change from that perspective anytime soon.  But the lack
of merge tracking is probably the only reason from the arguments I've
read that I would not be quick to branch if there's reason to believe
the changes are strong enough to potentially break trunk.

Otherwise I have to agree with Juan that branching any potentially
damaging, several revision change over time is the right way to do it.

I can't see feedback as a reason to keep things in trunk anymore then I
can understand third party code submittal as a reason to branch. These
are existential to keeping a clean trunk. And he existing subversion
feature-set lets you manage these scenarios without making
implementation decisions based on outside-the-box concerns.

-Mark