[ovirt-devel] PatternFly upgrade - how to handle JS dependencies

[Vojtech Szocs]

----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "devel" <devel at ovirt.org>, "Oved Ourfali" <oourfali at redhat.com>, "Juan Hernández" <jhernand at redhat.com>
> Sent: Tuesday, January 10, 2017 10:28:06 PM
> Subject: Re: PatternFly upgrade - how to handle JS dependencies
> 
> On Tue, Jan 10, 2017 at 1:00 PM, Vojtech Szocs <vszocs at redhat.com> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Greg Sheremeta" <gshereme at redhat.com>
> > > To: "Vojtech Szocs" <vszocs at redhat.com>
> > > Cc: "devel" <devel at ovirt.org>, "Oved Ourfali" <oourfali at redhat.com>,
> > "Juan Hernández" <jhernand at redhat.com>
> > > Sent: Monday, January 9, 2017 9:46:18 PM
> > > Subject: Re: PatternFly upgrade - how to handle JS dependencies
> > >
> > > On Fri, Jan 6, 2017 at 12:45 PM, Vojtech Szocs <vszocs at redhat.com>
> > wrote:
> > >
> > > > Hello,
> > > >
> > > > we'd like to upgrade the version of PatternFly (plus associated
> > libraries,
> > > > namely Bootstrap and jQuery) used in oVirt UI.
> > > >
> > > > Today, PatternFly stuff (PF + associated libraries) comes from
> > > > `patternfly1`
> > > > package hosted at Copr repo:
> > > >
> > > >   https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/
> > > >
> > > > Today, we require `patternfly1` as both Engine RPM build dependency
> > and the
> > > > Engine devel. env. dependency.
> > > >
> > > > To keep things simple, I'd like to propose the following approach:
> > > >
> > > > - create oVirt specific package, e.g. `ovirt-patternfly`, hosted at
> > Copr,
> > > >   containing PatternFly + associated libraries (Bootstrap, jQuery)
> > which
> > > >   are intended *specifically* for use by oVirt UI (hence the ovirt
> > prefix)
> > > >
> > >
> > > I've already done this, although it's currently named 'patternfly3'
> > > https://copr.fedorainfracloud.org/coprs/patternfly/patternfly3/
> >
> > I really think we should put some `ovirt` prefix there, to avoid
> > people thinking that it's some kind of general-purpose PatternFly
> > package.
> >
> > For example, `ovirt-engine-ui-dependencies` (for Engine GWT UI).
> >
> 
> That's fine. I had created the repo long before your suggestion, that's all.

I know, I just wanted to suggest the future change.

Having `patternfly3` right now allows us to experiment with upgrading
the PatternFly version in GWT UI so for the moment, I'm OK with that.

> 
> I think it should have 'js' in the name somewhere.

OK, this is Martin's suggestion actually =) ovirt-js-dependencies.

> 
> 
> >
> > >
> > > However, we want to move it to our ovirt infra because copr sometimes
> > goes
> > > down, and that breaks CI jobs.
> >
> > If we really want to do that, maybe we should add a new project
> > into releng-tools repo. The project would be at
> >
> >   releng-tools/specs/ovirt-engine-ui-dependencies
> >
> > containing package.json and build script that downloads JS dep's
> > and then packages all JS stuff as RPM.
> >
> > (Basically a very similar build process as with nodejs-modules.)
> >
> 
> Sure, that sounds good. Let me verify with infra where it should go.

Thanks.

Note that I'm totally OK with Copr too. But having an RPM built by
oVirt infra (with JS dependencies fetched in a way consistent with
e.g. nodejs-modules) indeed seems as the more correct approach.

> 
> 
> >
> > >
> > > So, +1 from me, but let's move to ovirt infra.
> > >
> > >
> > > >
> > > > - discontinue maintenance of `patternfly1` package at Copr
> > > >
> > > > - keep the existing approach: require `ovirt-patternfly` as both the
> > Engine
> > > >   build dependency and the Engine devel. env. dependency
> > > >
> > > > An alternative approach would be to introduce Node.js as Engine devel.
> > env.
> > > > dependency (use `npm install` to pull PF stuff), while using the
> > existing
> > > > ovirt-engine-{nodejs,nodejs-modules} packages for Engine RPM build.
> > > >
> > > > However, this alternative has some downsides, namely complication of
> > devel.
> > > > env. just to fetch the PF stuff. I don't like the idea of complicating
> > the
> > > > existing devel. env. just for the sake of fetching some 3rd party libs.
> > > >
> > > > I'm wondering what others think about this.
> > > >
> > > > Regards,
> > > > Vojtech
> > > >
> > >
> > >
> > >
> > > --
> > > Greg Sheremeta, MBA
> > > Red Hat, Inc.
> > > Sr. Software Engineer
> > > gshereme at redhat.com
> > >
> >
> 
> 
> 
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gshereme at redhat.com
>