<div dir="ltr"><div><div>Can we revisit this? We are currently blocked on a github PR (relevant to 2) - and could really use some process improvement as Honza suggested.<br><br></div>Thanks,<br></div>Jason<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 22, 2017 at 8:46 AM, Honza Pokorny <span dir="ltr"><<a href="mailto:honza@redhat.com" target="_blank">honza@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello folks,<br>
<br>
Over the last couple of months, it has become apparent that the process<br>
for releasing new versions of the two TripleO UI RPMs<br>
(openstack-tripleo-ui and openstack-tripleo-ui-deps) relies on manual<br>
work done by humans.  As a result, making changes to the specs of the<br>
said RPMs takes a long time, and causes delays in upstream CI.<br>
<br>
>From my point of view (read: I'm not familiar with the finer details of<br>
the inner workings of RDO), there are three manual tasks that need to be<br>
performed when a change to a spec is required (most often it's a new<br>
dependency):<br>
<br>
1.  Licensing review<br>
<br>
Obviously this step cannot be done by machines.  It has been suggested<br>
to us that it would simplify things for reviewers if we included<br>
transient dependency diffs as well --- we plan to do that going forward.<br>
<br>
2.  openstack-tripleo-ui-deps PR merge<br>
<br>
This step also cannot be done by machines.  However, we could streamline<br>
this work by handling the reviewing and merging by using the RDO Gerrit<br>
instead of GitHub.  I suspect that reviewers will be more likely to<br>
review these kinds of patches faster than by having to go to GitHub<br>
given that many of the other RDO projects are handled by Gerrit.<br>
<br>
3.  Rebuilding RPM and publishing it<br>
<br>
This step is the most opaque to the TripleO UI team.  Usually, we have<br>
to ask someone on IRC to rebuild the package.  Then, it seems to be<br>
published in two different places: CBS[1], which I understand to be a<br>
staging environment of some kind, and the other place is unknown to me<br>
but it's the place where the upstream CI can pick it up.  I have<br>
repeatedly asked to gain to some read-only access to the progress of<br>
these builds but have received none.  In order to speed up this work, I<br>
would love to see some more automation of the build process, and more<br>
visibility of the progress.<br>
<br>
It's very likely that my understanding of the problem is misguided, and<br>
I very much welcome your correction!  If you have suggestions on how the<br>
TripleO UI team can make RDO's life easier, I'm all ears.<br>
<br>
Thanks,<br>
<br>
Honza Pokorny<br>
<br>
[1]: <a href="https://cbs.centos.org/koji/packageinfo?packageID=4136" rel="noreferrer" target="_blank">https://cbs.centos.org/koji/<wbr>packageinfo?packageID=4136</a><br>
<br>
______________________________<wbr>_________________<br>
rdo-list mailing list<br>
<a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/rdo-list</a><br>
<br>
To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.<wbr>com</a><br>
</blockquote></div><br></div>