> On Jan 23, 2018, at 6:43 PM, Otto van der Schaaf <osch...@we-amp.com> wrote: > > Following a discussion over the Traffic Server dev list [1], I would like > to discuss approaches to moving over ats_pagespeed into the PageSpeed > project (as mentioned in the initial incubator proposal). We should > probably mark this plugin as experimental, as it is today in ATS. > > Moving the plugin into its own github repo would probably take the least > effort, but I think there are also some things speaking for merging > ats_pagespeed, ngx_pagespeed, and mod_pagespeed into a single repository: > > - A central place for the community to engage > - Currently ngx_pagespeed has mod_pagespeed as a submodule testing > dependency, which means that we periodically need to update the dependency > to point to the head of master to stay current > - Centralized developer (wiki) documentation > - We can (more easily) trigger CI runs for the other modules in CI when > making updates to the core libraries. > > If we want to move forward with merging, I would propose s simple > directory structure like: > > > */mod_pagespeed* > */ngx_pagespeed* > */ats_pagespeed* > *README.md* > *NOTICE* > *LICENCE* > *....* > > One concern is that merging the repositories may put additional burden on > those just wanting to build ngx_pagespeed or ats_pagespeed, as these > repositories currently are relatively lightweight. One thing that may be > worth looking into is if we can leverage newer git client features to > mitigate this. (e.g. sparse checkouts?).
So, we (ATS) tried the git sub-module ideas once, with miserable results. In theory it works, but in practice it sucked big time. For example, it makes it near impossible to build on VMs / boxes which do not have direct internet access, at least not without major shenanigans (since it can’t pull down the needed sub-modules at build time :-/). I’m not opposed to the sub-module idea, but my preference would be a single git repo, with the modules laid out as above. With some build options / trickery, it should be possible to automatically (or via configure options) detect where e.g. ATS is installed, such that it finds the necessary ATS include files etc. Yes, the git repo will be a lot bigger, but I personally think that is fine, and for Linux distro maintainers, it’d be a lot easier to build all the different RPMs right out of this one repo (so, one -lib RPM, one -devel RPM, one -nginx RPM, one -httpd RPM etc.). Cheers, — Leif https://git-scm.com/book/en/v2/Git-Tools-Submodules
