On Sat, Aug 22, 2015 at 06:31PM, Raul Kripalani wrote: > On Sat, Aug 22, 2015 at 5:56 PM, Konstantin Boudnik <[email protected]> wrote: > > > What exactly are you trying to solve ? To safe a few hundred kilos of > > source code not being fetched, but to push the complexity of the build, > > dependencies, and testing elsewhere? What's the clear win if you have > > separate repos? > > > Nah, not really the download size. That's secondary. > > You think putting each project in its own repo and linking them via Git > subtrees is the more complex than keeping it all in one repo?! I think > that's an early conclusion. There are things we haven't talked about, e.g. > project lifecycles, release lifecycles, continuous integration, releases > for different processor architectures and/or OS (C++), etc. In reality, > source code structure should go hand-in-hand with the type of organization > we pursue, so we should discuss that first.
I am a very empirical guy. I know for a fact from a few pretty bad experiences in the past that the split like that - unless _absolutely_ demanded by some forces outside of the development (e.g. legal requirements) - adds nothing but a massive headache. Thank you for bringing up release engineering, CI and all other things. Because that's exactly where the nightmares will be coming from down the road. > Hosting each project in a separate repo (and linking them via Git subtrees) > is beneficial for several reasons. Off the top of my head: > > * Independent – but related – lifecycles for each subproject. While all > projects are intertwined, being able to release .NET, CPP, Ignite Java > separately is fundamental for bugfixing. If the community hasn't talked > about this, now's a good idea to define a versioning policy and/or scheme. > Can each implementation evolve separately, i.e. with independent micro > versions (semver) if bugfixes are to be released ASAP for just a single > platform? Or do we keep all versions in sync and wait for a simultaneous > release? (à la Eclipse). Why do you want to release a C++ client separately from the platform? How you're going to guarantee the compatibility between the two? Who and who will be doing the pretty complex system testing in this case? > * Converging different build systems, each with its own release system, for > a different technology, inside the same repo may be confusing and > counter-intuitive for users. Just as a data point: I am a Bigtop guy. We have build a whole ecosystem and a framework to mitigate the complexities coming from what you just described. But we had to do it because we deal with 20+ different projects, running by different people. Why someone would like to create the hurdle like that for himself - is really beyond me. Let's not put the cart before the horse. Let's have the code transitioned first, ran through a couple of releases and then we'll see if separation is so beneficial for anyone in the community. Before that - it's just a moot academic reflection. Best, Cos > * If you want to fix a .NET or CPP bug, and want to create a branch > exclusively for that platform, I don't see why you should be branching all > off Ignite for all platforms. > > * Similarly, if we are allowing independent (but related) lifecycles for > each part, I don't see why a tag for a .NET bugfix, e.g. > ignite-dotnet-1.4.5 release should contain all of Ignite including CPP and > Java, especially if those versions are still on 1.4.3. That's plain > confusing, and with Git one cannot tag a specific region of the tree. > > Now from my personal experience: once you start cramming up several > heterogeneous projects that satisfy conditions like... > > (a) targeting different user bases / consumers (albeit some organisations > may use all 3 simultaneously). > (b) using different technologies and programming languages. > (c) may evolve with slightly different (but related) lifecycles. > (d) requiring different build systems with distinct CI setups each (for > .NET you'll need a Windows node on TeamCity). > (e) different release systems (e.g. for CPP you'll need to likely an > artifact per architecture). > (f) attracting contributors with different skills (few people are > proficient enough to work on Java, .NET and C++ simultaneously and > effectively). > > ... you're likely more inclined towards separating the code bases (and > linking them) rather than hosting everything inside one big repo. > > Regards, > > *Raúl Kripalani* > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source > Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk
