I am bit concerned about the number of repositories we are about to create on git and the relation between them.
Lets take an extension as an example: validation - reactor - api - core - examples - test-services If I understand correctly then we plan to create one git repo for each module above. So it would be 5 repos for the validation extension. I think this is quite problematic for several reasons. - If you change something in validation you often will change more than one of the modules above. - Like in svn today you can easily forget to update dependencies after a release. This results in the build not working anymore after the old snapshots are discarded by nexus. Addtionally you build with a potentially wrong set of dependencies in the meantime. In git this is even more problematic as you need to update several repos then to make changes instead just several directories in one svn tree. - It is difficult to do a build of the whole validation extension So I propose to rather use one repository per extension. Additionally I would also version and release the whole extension together. - This makes it easy to do and test changes that reach over more than one module - The release process is much easier and you can not forget to update dependencies Of course such a model creates some unnecessary artifacts in a release. For example you would get a new api bundle even when there are no changes in it. This is not very problematic though as we already version APIs on package level. So the user would still have full backwards compatibility. The difficult task in this model is of course which modules to bundle together in a repo. I think for extensions this is obvious but for other parts of sling it is less clear. As a good example that this approach can work see the apache aries project. In Aries we used to release each bundle individually. This created the same problems as in sling. We moved some projects to git but on a coarse grained level and it seems to work quite well. See these projects as examples: https://github.com/apache/aries-rsa https://github.com/apache/aries-jpa Each of those projects can be built in one step and the build is always consistently using the correct versions. A release can be done on top level in one step. Still for example the Aries RSA spi is still at package version 1.0.0. So external projects that build on it will still be compatible with the newest Aries RSA release. I know I am a it late to the party with my proposal but Robert encouraged me to still come up with it as after the move to git it will be too late. Best Christian 2017-10-17 11:52 GMT+02:00 Robert Munteanu <[email protected]>: > Hi, > > The discussions with infra are settling and I would like to schedule > the migration for tomorrow evening at 22:00 CEST. I am not sure of the > "downtime", but hopefully it won't be more than a couple of hours. > > Some final notes: > > - there is no access to features that require administrative access to > the repos. That includes, but not limited to: travis integration, > setting descriptions, tags, certain kinds of bots. > - infra is ok with this migration, but is likely to be overwhelmed if > we are going to have requests that require manual intervention to our > 200+ repositories. We are expected to assist ( e.g. by providing > scripts ) should too many repositories need attention or break > - there is at least one project that is scaling down its number of git > repositories (couchdb), mainly due to (quoting): > > a) PRs on different repos for the same semantic change need unusual > coordination to land, intermittent CI will break, or needs > extra tooling. > b) Keeping main dependency list updated by hand is tedious (can be > automated tho). > c) Doing branches/tags/releases synchronised across all repos is a > pain (can be automated, but is an extra layer of hassle either way). > > For me personally all of these are fine, and I expect that the > improvements brought by Git will offset the downsides. I want to make > sure though that everyone is aware of these and and considers that the > SVN to Git migration can proceed. > > Please speak up if you find something of concern. > > Thanks, > > Robert > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Computer Scientist http://www.adobe.com
