Am Fr., 31. Aug. 2018 um 01:28 Uhr schrieb Doug Hellmann
> | Packaging-rpm | 4 repos |
We're ready - please send the patches.
OpenStack Development Mailing List (not for usage
Am Mo., 13. Aug. 2018 um 11:08 Uhr schrieb Alberto Planas Dominguez
> I will change my role at SUSE at the end of the month (August 2018), so
> I request to be removed from the core position on those projects.
Sad to see you go, but I appreciate the heads up and wish you all the
I would like to ask for a exception to add tooz 1.60.0 to
stable/queens. As part of the msgpack-python -> msgpack switch over we
dependencies, but the tooz release did not include the dependency
switch (not sure why, the branch point was just before the fix).
As it is a one
2018-02-08 11:05 GMT+01:00 Bedyk, Witold :
> I would like to request FFE for monasca-common to be bumped in upper
> constraints. The version has been bumped together with the rest of Monasca
> components . Monasca-common is used only in Monasca projects .
2018-01-30 16:53 GMT+01:00 Matthew Thode :
> LGTM, +2
OpenStack Development Mailing List (not for usage questions)
2017-12-13 17:17 GMT+01:00 Thierry Carrez :
> - We'd only do one *coordinated* release of the OpenStack components per
> year, and maintain one stable branch per year
> - We'd elect PTLs for one year instead of every 6 months
> - We'd only have one set of community goals
Thanks for looking into this. I do watch devstack changes every once in a
while but couldn't catch this one in time. The missing pmap -XX flag
problem has been there forever but it used to be non fatal. Now it is,
which is in principle a good change.
I will make sure that it passes
2017-02-16 15:43 GMT+01:00 Igor Yozhikov :
> I’d like to nominate Alberto Planas Dominguez known as aplanas on irc for
> Packaging-RPM core.
> Alberto done a lot of reviews for as for project modules , as for rest
> of OpenStack components . His
2017-01-27 13:51 GMT+01:00 Davanum Srinivas :
> I've consolidated the changes to the upper-constraints into One single review:
I'm ok with it if we have release team buy in.
your feedback appreciated. I really like it :)
-- Forwarded message --
From: Heidi Joy Tretheway
Date: 2016-10-19 20:59 GMT+02:00
Subject: Your draft logo & a sneak peek
We welcome you to *share this logo with your team
>> Gates that do not leave verified +1 are called non-voting, so
>> logically gates that leaves verified +1 are called voting gates.
Eh, what I wanted to +1 was:
+1 to promote the check jobs on rpm-packaging from MOS and SUSE CI as
Sorry for mixing up definitions and then
2016-09-29 14:12 GMT+02:00 Haïkel :
> Gates that do not leave verified +1 are called non-voting, so
> logically gates that leaves verified +1 are called voting gates.
Am 13.09.2016 05:03 schrieb "Tony Breeds" :
> > The reviews are:
> > update constraint for XStatic-Bootstrap-SCSS to new release 22.214.171.124
> > https://review.openstack.org/#/c/368970/
> > update constraint for XStatic-smart-table to new release 126.96.36.199
OpenStack RPM Packaging would like to update to pymod2pkg 0.5.4:
this package is only used by packaging (renderspec and rpm-packaging
git repos) that are on a release-independent schedule (iirc we're
tagged as never-release) and
2016-09-09 9:42 GMT+02:00 Tony Breeds :
> Has some impact on octavia (doc-requirements) and rpm-packaging (internal
Yeah, rpm-packaging shouldn't be a blocker on this, since we're just
trying to keep a snapshot of g-r that we have
> This is the FFE to get this change in for newton:
> The os-vif 1.2.1 release was a bug fix patch release to get a high priority
> bug  in for newton that is impacting the neutron linuxbridge job in the
> gate .
> So we already have
I would like to suggest Javier Peña as an additional core reviewer for
the packaging-rpm core group. He's been an extremely valueable
contributor recently both doing regular reviews on the PRs as well as
contributing more to the packaging effort overall.
> Cleaning up the readme makes a lot of sense. If we end up wanting to
> split it a lot, I'd suggest moving some of the "consumer" facing info to
> the project team guide, but it's moderately less easy to change there
> because the reviewer group is different.
.. which is a good thing,
I've updated https://wiki.openstack.org/wiki/Requirements#Contact (and
also the rest of the wiki page) with newer information
about global-requirements handling. Please if you find issues related
to the global requirements update process in your project
don't hesitate to join the
2016-05-19 1:08 GMT+02:00 Robert Collins :
> It's already fully documented in the requirements repo README; if
> there is no link to that from the project-guide, we should add one,
> but I would not duplicate the content.
Agreed. The project driver guide is not very
> That works for me. I'd prefer that meeting earlier in the week so perhaps
> a UTC 11:00 Tuesday would be a good time to use until DST changes and then we
> can re check based on who is active.
Works for me. thanks for the writeup in the etherpad, that was very
helpful. Lets meet on
I'd like to announce my candidacy for the RPM Packaging for OpenStack PTL. I
am putting up the candidacy because I would feel honored to continue doing the
PTL role, but I'm also fine with passing on the torch. At the end of the
day what matters is that the project becomes successful
> I'd like to propose new candidates for RPM packaging core reviewers:
> Alan Pevec
> Jakub Ruzicka
OpenStack Development Mailing List (not for usage questions)
> Ha, I'm surprised you forwarded this. But thanks. :)
Yeah, I guess I need to be more explicit on where my mails should be
forwarded to without even asking me next time..
I apologize wholeheartedly.
> Also, this is the first time Neutron has been more popular/buzzworthy than
I'd like to announce my candidacy for the RPM Packaging for OpenStack PTL.
During the Liberty cycle I've been co-PTL'ing this together with Haïkel
Guemar as a bootstrap. For the Mitaka cycle we've been notified that this
setup needs to be adjusted to a single PTL. Therefore we discussed this
extraction of the meeting minutes from
we agreed to switch to the standard way of doing meeting minutes once
the infra review got merged. its a bit of a short minutes, feel free
to reach out to number80 or me in case you have
Hello OpenStackers, hello TC,
Haikel and I have just submitted an update to the change to the governance
repo to add RPM packaging to the OpenStack projects:
As a start there we'd like to do a dual PTL from Red Hat (Haikel) and SUSE
(myself) and we'd like
An example of some specs already doing this (they are built using the
cheetah template engine/style):
They are turned into 'normal' spec files (the compilation part)
during build time.
A couple of packagers from RDO and SUSE met today on IRC to kick off
brain storming on unified upstream rpm packaging for OpenStack.
Please note: there are currently two movements going on: RDO would
like to move their Liberty packaging from github.com and gerrithub to
openstack gerrit, and
I'm just kind of curious ... as both the RDO and SUSE folks look closer
at this, how big are the differences?
From the overall big picture, we're doing pretty much the same thing.
We have both a tool chain to continuously track changes as they happen
in upstream git, packaging that
I selected these 80 to move all of what RDO is currently maintaining on
gerrithub to review.openstack.org, this was perhaps too big a set and in RDO
we instead may need to go hybrid.
Yeah, In my opinion we ahve lots of repeated divergence between the
different python modules, so
2015-06-09 0:34 GMT+02:00 Derek Higgins der...@redhat.com:
This patch would result in 80 packaging repositories being pulled into
I personally would prefer to start with fewer but common packages
between all RPM distros (is there more than Red Hat and SUSE ?) than
2014-10-02 14:19 GMT+02:00 Duncan Thomas duncan.tho...@gmail.com:
What is actually needed is those who rely on the stable branch(es)
existence need to step forward and dedicate resources to it. Putting
the work on people not interested is just the same as killing them
off, except slower,
I'm adding a couple of people on cc: with an interest in Ubuntu and SUSE
packaging: the Horizon team would love to have your opinion on this (it
came up during our weekly meeting).
I was somehow not CC'ed although I'm the SUSE packager for OpenStack.
In my opinion a) is the option
When I was an operator, I regularly referred to the sample config files
in the git repository.
The sample config files in git repository are tremendeously useful for
any operator and OpenStack Packager. Having them generateable with a
tox line is very cumbersome.
As a minimum those config
- some packages use different usernames
- some put things in different places (and all of them use different
places to the bare metal ephemeral device layout which requires
- possibly more in future.
Somehow I miss between your suggestions of option #A and #B
were not appropriate for real deployment, and our puppet modules were
not providing better values
I'd agree that raising the caching timeout is a not a good production
default choice. I'd also argue that the underlying issue is fixed
Here is what I tried:
/opt/stack/cinder $ ./tools/lintstack.sh
But this does not report any errors even though I am on the same branch.
What am I missing?
You might be running against local packages then which have a
different version / output. The proper way to reproduce the Gate
Hi Zhi Qiang,
for i.e. the hacking rule h233 in hacking looks not so robust,
it cannot detect
\bprint xxx, (\s+
It currently detects both as a violation of the rule, which is IMHO
correct. Please note that
Cinder uncapping python-keystoneclient will get us past this.
There is a review exactly proposing that:
Though I'm not
quite sure how we got to this break point in the first place.
I think this is due to the django_openstack_auth breakage
Let's submit a multi-project bug on launchpad, and be serious for changing
these global requirements in following days
OpenStack-dev mailing list
Indeed. The whole idea behind a single release channel for python client
libraries was that you should always be running the latest, as they
should drastically enforce backward compatibility.
Well, backward compatibility can be tricky when it comes to test.
We've for example
See for example https://bugs.launchpad.net/horizon/+bug/1196823
This is arguably a deficiency of mox, which (apparently?) doesn't let us mock
I agree, but it is just one example. other test-only issues can happen as well.
Similar problem: the *client packages are
Mail list logo