<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 6, 2017 at 12:45 PM, Vojtech Szocs <span dir="ltr"><<a href="mailto:vszocs@redhat.com" target="_blank">vszocs@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
we'd like to upgrade the version of PatternFly (plus associated libraries,<br>
namely Bootstrap and jQuery) used in oVirt UI.<br>
<br>
Today, PatternFly stuff (PF + associated libraries) comes from `patternfly1`<br>
package hosted at Copr repo:<br>
<br>
<a href="https://copr.fedorainfracloud.org/coprs/patternfly/patternfly1/" rel="noreferrer" target="_blank">https://copr.fedorainfracloud.<wbr>org/coprs/patternfly/<wbr>patternfly1/</a><br>
<br>
Today, we require `patternfly1` as both Engine RPM build dependency and the<br>
Engine devel. env. dependency.<br>
<br>
To keep things simple, I'd like to propose the following approach:<br>
<br>
- create oVirt specific package, e.g. `ovirt-patternfly`, hosted at Copr,<br>
containing PatternFly + associated libraries (Bootstrap, jQuery) which<br>
are intended *specifically* for use by oVirt UI (hence the ovirt prefix)<br></blockquote><div><br></div><div>I've already done this, although it's currently named 'patternfly3'</div><div><a href="https://copr.fedorainfracloud.org/coprs/patternfly/patternfly3/">https://copr.fedorainfracloud.org/coprs/patternfly/patternfly3/</a><br></div><div><br></div><div>However, we want to move it to our ovirt infra because copr sometimes goes</div><div>down, and that breaks CI jobs.</div><div><br></div><div>So, +1 from me, but let's move to ovirt infra.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- discontinue maintenance of `patternfly1` package at Copr<br>
<br>
- keep the existing approach: require `ovirt-patternfly` as both the Engine<br>
build dependency and the Engine devel. env. dependency<br>
<br>
An alternative approach would be to introduce Node.js as Engine devel. env.<br>
dependency (use `npm install` to pull PF stuff), while using the existing<br>
ovirt-engine-{nodejs,nodejs-<wbr>modules} packages for Engine RPM build.<br>
<br>
However, this alternative has some downsides, namely complication of devel.<br>
env. just to fetch the PF stuff. I don't like the idea of complicating the<br>
existing devel. env. just for the sake of fetching some 3rd party libs.<br>
<br>
I'm wondering what others think about this.<br>
<br>
Regards,<br>
Vojtech<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Greg Sheremeta, MBA<br>Red Hat, Inc.<br>Sr. Software Engineer<br><a href="mailto:gshereme@redhat.com" target="_blank">gshereme@redhat.com</a><br></div></div></div>
</div></div>