[asterisk-scf-dev] Consolidate git repos?

[Kevin P. Fleming]

On 10/13/2010 11:31 AM, Russell Bryant wrote:
> On Wed, 2010-10-13 at 07:57 -0500, Kevin P. Fleming wrote:
>> On 10/13/2010 07:35 AM, Russell Bryant wrote:
> 
>>> It's also just an issue with barrier to entry to contribute.  It's just more work on the contributor to have to generate a patch for every repo and work with the code review process/tool to push each one through the workflow.  It would be easier to contribute (and easier for the reviewer IMO) if more code was together.
>>
>> There aren't patches to be generated. The contributor makes their
>> changes, pushes them to a team developer repository, and when they are
>> ready to be reviewed, they get pulled into a branch in the relevant
>> integration repository... where they can be reviewed, modified, etc.
>> until they are ready for merging.
> 
> Ok, well whatever the contribution process is going to be ... git
> clones, branches, code reviews in some web app, whatever ... is x number
> of components more work to move the change through the process if the
> change has wide reaching scope.  I would expect those type of changes to
> be common in early development.
> 
> For example, in an earlier message, I identified some small proposed
> changes to the Session and SessionListener interfaces.  I can code it
> and run tests in less than an hour, I'm sure.  To submit it, I would
> have to change 4 repositories, I think (slice, routing, bridging, sip).
> I would have to push 4 modified git clones into my team area, push those
> changes into 4 different integration repositories, create 4 different
> review requests in a code review system, and eventually push changes to
> 4 different release repositories.  That just seems like more work than
> it should be to me.
> 
> I'm coming at this as a potential contributor with a desire to maximize
> how much I can accomplish with the small amount of personal time I am
> able to devote to this.  People have complained about the increased
> barrier to contribution to Asterisk just by adding the requirement of
> getting code peer reviewed.  Reducing the barrier to contribution is one
> of many critical factors to help ensure that Asterisk SCF succeeds in
> building an open source development community, and isn't 100% developed
> by the team paid to do so as their full time job.
> 
> If it really is the right thing to do to keep fine grained repositories,
> I trust the decision of the team.  I just request that barrier to entry
> for contributors (and ease of packaging and understanding by the user
> community, as discussed in other parts of this thread) is heavily taken
> into account in the decision.

We had a long discussion about this yesterday, and the result of that
will be put onto a page on the wiki in the next couple of days, and then
a request posted here to review and discuss it. Stay tuned :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org