[rdo-list] TripleO UI Packaging Strategy

[Haïkel]

2016-07-19 16:08 GMT+02:00 Florian Fuchs <flfuchs at redhat.com>:
>
>
> So a couple of questions, assuming/suggesting the following workflow:
>
>
> 1. In a first step, we make sure the build tools and dependencies exist as
> node modules on the build system, so it can compile the target JS files from
> it. We make sure all dependencies have compatible licenses.
>
> 2. On each new tripleo-ui release, the build system compiles new target JS
> files using the dependencies from step 1.
>
> 3. The build system adds the compiled files to the new package (which is
> otherwise based on the tripleo-ui distgit repo).
>
>
> Questions:
>
> - Is this workflow plausible/acceptable/feasible?
>

Yes, though I'm not sure what you understand as build system.
Build system has no internet access, and except baseOS, only things
available are provided sources + dependencies declared as
BuildRequires (must be packaged)

> - If it is, would that flow be good acceptable for now only, or even
>  permanently, given that all sources are free software and the build is
>  transparent and reproducible?
>

That's the stable state we want to reach.
Depending the amount of work needed, we may tolerate temporary
exceptions, but they have to be approved by RDO maintainers in our
weekly meeting.

> - Would version changes for dependencies have to be reviewed separately or
>  could they be updated with each new build based on the version information
>  in the upstream repo's package.json file?
>

Process is:
* initial review when you introduce new package (except if it's
packaged in Fedora as they have exemption from legal team)
* update bumps are done directly without peer reviewing (well release
wranglers and CI are checking sanity)

> - Could steps 1. and 2. be combined, so tools and dependencies are updated
>  and installed on each new release? (Assuming dependency changes are
>  reviewed beforehand.)
>
>
> Thanks for clarifying!
> Florian
>

Up to a certain extent, while we tolerate bundling web assets, I
prefer that we don't bundle the toolchain and try to keep it stable.
Not that we'd enforce strict constraints on that, but remember that we
have limited ressources to maintain the whole distribution.

Regards,
H.