Lieutenant needed: build and release process

[Brad Roberts via Digitalmars-d]

Personally, I've never found the multiple repositories inconvenient. 
About the only place they are are when simultaneous changes are required 
to more than one of the parts.  That's INTENDED to be rare since it 
directly implies a non backwards compatible change.  Those changes tend 
to hurt people and making it more obvious that it's happening and making 
the bar a little higher to leap isn't a bad thing.

About the only pro listed below that I can agree with is the atomic 
commit issue (see above for my feelings on those) and the regression 
hunt.  There's already tooling to deal with the latter, and it works 
pretty well.  The rest fall into the "yes, you're right, but the benefit 
it minimal at best.

The con's are more significant to me.  The permissions issues.  The 
enforced layers.  The fact that the cost of change isn't small and the 
benefits from the change are small.

I vote no.

If I had to do it all over again, I'd still split them up.

On 9/8/2014 2:24 PM, Dragos Carp via Digitalmars-d wrote:
> On Monday, 8 September 2014 at 20:56:51 UTC, Vladimir Panteleev
> wrote:
>> On Monday, 8 September 2014 at 19:51:58 UTC, Dragos Carp wrote:
>>> I have collected a few pros/cons about merging the repositories:
>>
>> This topic has been discussed in the past. Some more points that I can
>> think of:
>>
>>> Pro:
>>> - simplified release tagging and branching
>>> - atomic commit of cross-repository changes
>>> - easier to experiment with cross-repository feature branches
>>> - single pull request queue offering a better overview about the
>>> project
>>> - easier grep, easier build
>>> - simplified build documentation
>>
>> - easier to run the entire test suite
>> - much easier "git bisect"
>>
>>> Cons:
>>> - migration effort (documentation, merge scripts)
>>> - current work-flow adjustments
>>> - the resulted repo history could be sometimes confusing
>>> - lost github pull-request history
>>
>> - more difficult to assign ownership/responsibility
>
> The directory structure will still be present. I don't think that
> would be a problem, it works pretty well for bigger projects.
>
>> - forking just one component becomes more difficult
>
> Forking a component is a seldom event, working with all three is
> the rule and we should strive to optimize it.
>
>> - more mixing of free and non-free source code in the same repository
>> (although I heard splitting the DMD repo into two (frontend and
>> backend) repositories was being discussed)