Stefan Sperling wrote:
> Philip Martin wrote:
>> Julian and I talked about this yesterday, I'll try and explain a few
>> things.
>> [...]
>
> This makes a lot of sense. But it doesn't explain why this code
> needs to be merged to trunk. The investigation could just as well
> continue on a branch, could it not?
> Because it doesn't sound like what's holding us back is the branch.
>
> Is encouraging more collaboration on this project the only reason
> for merging to trunk? If so, why do you expect more collaboration
> because of this merge? If someone is genuinely interested, the cost
> of checking out and building another branch is not very high.
Yes, it's totally about increasing ease of collaboration. I think
other devs will want to work on this and making it easy as possible is
critical -- working on a branch is too solitary. Thanks for your
comments on this on IRC just now:
<julianf> I do feel very isolated.
Having a good conversation just now, but generally not.
<stsp> yes, that's been a problem for a long time
<julianf> Yes, reason for merging to trunk is increased visibility and
ease of participation by other devs.
<stsp> to be clear: i'm not against the idea, i just want to know
whether you're making this decision on those grounds or not
<julianf> If a dev (Bert, say) is working on RA serf, say, in trunk or
in his own branch, it's extra effort for him to take a quick look at
what I've changed in my branch.
<julianf> If it's in the same branch, it's already there in the WC
whenever he does 'update', and the tests run whenever he runs the
tests, and so he can quickly run a test in verbose mode to look at the
output, or quickly run 'svnmover <something>' just to see what it
does,
in response to seeing something in IRC or dev@ or in a commit notification.
And don't you agree we have a policy of 'trunk unless good reason not to'?
<stsp> yes, as long as it's done in a non-intrusive way, that's fine
the editorv2 story went the same path iirc
it's on trunk, but we don't really use it
it is still possible that the merge might not result in more collaboration
but there's no way to know ahead of time
what's the alternative? you end up losing energy for this project,
working in too much isolation?
in that case, definitely merge and see what happens
i would not like to see this project going nowhere
<julianf> Cool, thanks, stsp, yes, that about sums up how I feel about
it. I'll try to make it as unobtrusive as possible.
- Julian
Received on 2015-11-13 13:16:45 CET