[asterisk-scf-dev] Consolidate git repos?

[Russell Bryant]

> 
> We've used separate git repos for a number of reasons, but one of the
> biggest is that it is the 'git way', which is driven by the fact that
> branches and tags in git are for the *entire* repository (unlike
> Subversion, where they are just a directory copy in the tree). If two
> components are in the same git repo, they'd have to have identical
> branching and tagging schedules and releases, or the branches/tags
> would have to incorporate component names in their own names. In addition,
> since it's not possible to partially clone a git repo, if someone
> wanted to work on a single component, they'd be forced to clone the entire
> consolidated repo.

I guess I haven't messed with very many projects that use git.  Linux at least has it all packed into one.  What are some examples of a project that has their repos organized more like this?  I'd be curious to look around.

Personally, I don't see a problem with tagging/releasing everything together.  It's at least easier to manage from a release management perspective, and easier to understand as a consumer of the platform.

> Personally I see no problem with a patch that changes the published
> APIs being posted, reviewed and merged on its own before the changes to the
> components that implement those APIs (and eventually the components
> that consume the APIs as well). We may learn later that it's more
> cumbersome than we are expecting, who knows :-)

If it's separate, then once the slice change goes in, the builds of all of the components may be broken, right?  I know that there has been a lot of discussion and planning regarding interface versioning, but I would expect that in the near term there will likely be a lot of heavily invasive development where it's not really worth it to maintain backwards compatibility since the platform is not being consumed in production.  Either every change has to be backwards compatible or it all goes in at the same time?

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.

(On a totally unrelated sidenote, it appears that this mailing list is configured such that when you reply, it goes to both the sender of the last message as well as the list itself, instead of only to the mailing list.)

--
Russell Bryant
Digium, Inc.  |  Engineering Manager, Open Source Software
445 Jan Davis Drive NW   -    Huntsville, AL 35806  -  USA
jabber: rbryant at digium.com    -=-    skype: russell-bryant
www.digium.com -=- www.asterisk.org -=- blogs.asterisk.org