[openstack-dev] [Horizon] Updating XStatic packages
r1chardj0n3s at gmail.com
Tue Jan 12 02:01:07 UTC 2016
In terms of process, obviously updating the data in the xstatic is
relatively easy (for most packages) but I wonder from a review standpoint
what sort of process we should have here. To approve a merge of an xstatic
package update, I feel like I should have, in order of preference:
1. a link to the change notes for the project in question so I can see what
the impact of the update is, or
2. a list of those changes in the bug or change message for the xstatic
update (i.e. the relevant information from #1), and
3. an explanation of what existing problems are being solved in Horizon
through the update (if any) or what impact there will be on Horizon with
the upgrade (i.e. an examination of #2 in the context of Horizon).
I know that we often need to justify package updates to downstream
packagers, and having this information will certainly help our case. Or is
this all a bit too much burden?
On 7 January 2016 at 04:36, Rajat Vig <rajatv at thoughtworks.com> wrote:
> I did update some of the low hanging packages where the upgrades seemed
> safe to do and noted the patch numbers in the same EtherPad.
> I wasn't sure what to mark the effort against. So I created some bugs.
> Should it be a blueprint?
> On Wed, Jan 6, 2016 at 2:18 AM, Rob Cresswell (rcresswe) <
> rcresswe at cisco.com> wrote:
>> Hi all,
>> While the automated system is broken, I’d like to work on manually
>> releasing a few of the XStatic packages. This will *only* be the release
>> stage; we will still use gerrit to review the package content as usual.
>> List of packages current versions, and their upstreams, can be found
>> here: https://etherpad.openstack.org/p/horizon-libs
>> If anyone has spare time, please consider investigating some of the
>> dependencies listed above. To update an XStatic package, propose a change
>> to its repo as you would with Horizon; they are all in the OpenStack
>> namespace. For example, Xstatic-Angular can be found at
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev