pagespeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maksim Orlovich <morlov...@google.com.INVALID>
Subject Re: [DISCUSS] moving ats_pagespeed and merging repo's
Date Wed, 24 Jan 2018 14:54:28 GMT
Single repo seems nicer wrt to atomic commits, at least, though our build
story is quite a mess.
Maybe I should stop being lazy and port everything to cmake and abseil or
something, except it's not
clear how that would integrate with existing server build systems anyway.

We also require sub-modules heavily to build mod_pagespeed/PSOL, though, so
I am not sure whether you really
gain that much in that respect --- for distro build we've been using this
rather brittle script:
https://github.com/apache/incubator-pagespeed-mod/blob/master/devel/create_distro_tarball.sh
... which bundles up the "unusual" stuff but keeps things like libpng and
zlib out.



On Wed, Jan 24, 2018 at 2:08 AM, Leif Hedstrom <zwoop@apache.org> wrote:

>
>
> > On Jan 23, 2018, at 6:43 PM, Otto van der Schaaf <oschaaf@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message