[asterisk-scf-dev] Consolidate git repos?

[Kevin P. Fleming]

On 10/13/2010 07:35 AM, Russell Bryant wrote:

> 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.

The Linux kernel is a single component, and there aren't parts of it on
different release tracks or that are easily usable without the rest. As
a small example, Git itself contains some ancillary tools in the Git
repo that are not on the same release schedule, and the Git maintainers
are working on pulling them out for this very reason.

> 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.

That can still be done even if the components live in separate
repositories, through the magic of smart scripting :-)

>> 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?

Backwards compatibility is the name of the game, yes. In addition, this
is why we plan to have (currently undocumented) 'release' and
'integration' repositories, with the idea being that the 'master' branch
(and any other branches) in the 'release' repositories are always
ready-for-use. The 'integration' repositories are where work-in-process
would live in branches until ready for merging into the 'release'
repositories, and with git it's pretty trivial to pull in a branch from
a different repository when needed. It would even be possible to come up
with some magic in the 'gitall' repository that allowed a user to
identify which components they wanted from the 'release' repos and which
from the 'integration' repos.

> 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.

> (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.)

I just hit 'reply' in Thunderbird and that didn't happen for me... when
I created the list I copied the config from the asterisk-dev list, so it
shouldn't be setup that way... but if others are seeing it too, I'll
look into it.

-- 
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