Am Fr., 31. Aug. 2018 um 01:28 Uhr schrieb Doug Hellmann
:
Hi Doug,
> | Packaging-rpm | 4 repos |
We're ready - please send the patches.
Greetings,
Dirk
__
OpenStack Development Mailing List (not for usage question
Hi Alberto,
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
be
Hi,
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
converted all
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 line
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 [1]. Monasca-common is used only in Monasca projects [2].
The changes between 2.7.0 and 2.8
2018-01-30 16:53 GMT+01:00 Matthew Thode :
> LGTM, +2
+2
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/c
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 per year
> - We'd have onl
Hi David,
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 aga
Hi Igor,
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 [1],[2] as for rest
> of OpenStack components [3]. His experience within OpenStack com
Hi Dims,
2017-01-27 13:51 GMT+01:00 Davanum Srinivas :
> I've consolidated the changes to the upper-constraints into One single review:
> https://review.openstack.org/#/c/426116/
I'm ok with it if we have release team buy in.
Greetings,
Dirk
Hi all,
your feedback appreciated. I really like it :)
Greetings,
Dirk
-- 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 and discuss it in
Barcelo
Hi,
>> Gates that do not leave verified +1 are called non-voting, so
>> logically gates that leaves verified +1 are called voting gates.
> +1
Eh, what I wanted to +1 was:
+1 to promote the check jobs on rpm-packaging from MOS and SUSE CI as
voting jobs.
Sorry for mixing up definitions and then
Hi,
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.
+1
Greetings,
Dirk
__
OpenStack Development Mailin
Am 13.09.2016 05:03 schrieb "Tony Breeds" :
> > The reviews are:
> >
> > update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1
> > https://review.openstack.org/#/c/368970/
> >
> > update constraint for XStatic-smart-table to new release 1.4.13.2
> > https://review.openstack.org/#/c/3
Hi,
OpenStack RPM Packaging would like to update to pymod2pkg 0.5.4:
https://review.openstack.org/#/c/367388/
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
since we're packaging,
Hi Tony,
2016-09-09 9:42 GMT+02:00 Tony Breeds :
> Has some impact on octavia (doc-requirements) and rpm-packaging (internal
> global-requirements.txt)
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 tested against (this
isn't f
Hi Matt,
> This is the FFE to get this change in for newton:
>
> https://review.openstack.org/#/c/365165/
>
> The os-vif 1.2.1 release was a bug fix patch release to get a high priority
> bug [1] in for newton that is impacting the neutron linuxbridge job in the
> gate [2].
>
> So we already have t
Hi,
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.
See http://stackalytics.com/?user_id=j
Hi Doug,
> 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, r
Hi all,
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 #openstac
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 explicit on this
(http://docs.
> 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 #opensta
Hi everyone,
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
Haikel,
> I'd like to propose new candidates for RPM packaging core reviewers:
> Alan Pevec
> Jakub Ruzicka
+1
Greetings,
Dirk
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
Hi,
> 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
> Nova?
Oh, it
Hi,
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
Hi,
extraction of the meeting minutes from
https://etherpad.openstack.org/p/openstack-rpm-packaging
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 questions.
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:
https://review.openstack.org/#/c/191587
As a start there we'd like to do a dual PTL from Red Hat (Haikel) and SUSE
(myself) and we'd like
Hi Joshua,
> An example of some specs already doing this (they are built using the
> cheetah template engine/style):
>
>
> https://github.com/stackforge/anvil/tree/master/conf/templates/packaging/specs
>
> They are turned into 'normal' spec files (the compilation part)
> during build time.
>
Rig
Hi Russel,
> 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 tha
Hi,
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 R
Hi Derek,
> 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 g
Hi Derek,
2015-06-09 0:34 GMT+02:00 Derek Higgins :
> This patch would result in 80 packaging repositories being pulled into
> gerrit.
I personally would prefer to start with fewer but common packages
between all RPM distros (is there more than Red Hat and SUSE ?) than
starting the process with
Hi Julie,
> 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
2014-10-02 14:19 GMT+02:00 Duncan Thomas :
Hi,
> 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, messier and creatin
Hi,
>> 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 con
>> were not appropriate for real deployment, and our puppet modules were
>> not providing better values
>> https://bugzilla.redhat.com/show_bug.cgi?id=1064061.
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
Hi Robert,
> So far:
> - 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
> /mnt/).
> - possibly more in future.
Somehow I miss between your suggestions of option #A an
Hi,
> 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
e
Hi Zhi Qiang,
> for i.e. the hacking rule h233 in hacking looks not so robust,
> https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L345
> it cannot detect
>
> \bprint$
> \bprint >>>xxx, (\s+
It currently detects both as a violation of the rule, which is IMHO
correct. Please not
Hi Matt,
Given that the Nova API is public, this needs to be validated in the API,
otherwise the security guys are unhappy.
Of course the API shouldn't get bad data in the first place. That's a bug
in nova client. I have sent reviews for both code fixes but I've not seen
any serious reaction or a
>> See for example https://bugs.launchpad.net/horizon/+bug/1196823
> This is arguably a deficiency of mox, which (apparently?) doesn't let us mock
> properties automatically.
I agree, but it is just one example. other test-only issues can happen as well.
Similar problem: the *client packages are
Hi Thierry,
> 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 rec
> Let's submit a multi-project bug on launchpad, and be serious for changing
> these global requirements in following days
https://bugs.launchpad.net/keystone/+bug/1200214
created.
Greetings,
Dirk
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
Hi Sean,
> Cinder uncapping python-keystoneclient will get us past this.
There is a review exactly proposing that:
https://review.openstack.org/#/c/36344/
> 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 breakag
44 matches
Mail list logo
