c. If you need minor fixes or brown paper
wrapper, there's always 1.1, or 1.0.1, or whatever available in
between.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ves, do the
equivalent repositories in Gerrit get decommissioned at that point?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s we use at times when there are a lot
of changes being gated and failure rates climb (without this measure
we were entering something akin to virtual memory swap paging
hysteresis patterns, but with virtual machine quotas in providers
instead of virtual memor
ing-in-parallel
http://docs.openstack.org/infra/publications/zuul/#(18)
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
entation teams would love to have
help improving the status quo. You may also want to post a more
specific offer to help on the openstack-d...@lists.openstack.org
mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
--
Jeremy Stanley
___
back clean.
Separately, https://review.openstack.org/98947 adds the overlap of
Sphinx versions which should have been present in the change
triggering these failures but has not been approved by requirements
core reviewers yet.
--
Jeremy Stanley
___
Op
e OpenStack party being thrown by
the local OSUG on the 24th:
http://www.meetup.com/Triangle-OpenStack-Meetup/events/188128342/
I'm sure it'll be a blast--tell everyone I said hi!
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenSta
stream project. Also
the git notes on commits we added will include identifying details
such as the URL to review.openstack.org, which should help to
differentiate them.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@list
resolves the issue. If so, I'll
make sure we prioritize merging it ASAP to get client gating
unwedged and follow up to this thread with relevant updates.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists
On 2014-03-10 18:33:14 + (+), Jeremy Stanley wrote:
[...]
> Monty originally proposed an improvement to the way we bootstrap
> setuptools on our job workers which ought to help with this, so
> I'll see whether it's in shape and still resolves the issue. If
>
ly also some StackForge projects which have put
in requests for renames. Updates will be provided in the
#openstack-infra and #openstack-dev channels on the Freenode IRC
network. Once completed, I'll follow up to this mailing list thread
as well.
--
Jeremy Stanley
signature.asc
Descript
On 2014-03-11 04:29:04 + (+), trinath.soman...@freescale.com wrote:
> +1
>
> Attending
Note that announcement was for yesterday. Nobody showed up with
questions so it ended very early.
--
Jeremy Stanley
___
OpenStack-dev mai
led between 12:45 and
13:00 (the workspace log will mention a failure to fetch the origin
remote for openstack/savanna if so).
A minor issue with some recent statusbot improvements left stale
topics in a lot of channels, but I have manually corrected them all
at this point and a fix is already in rev
On 2014-03-10 21:56:57 + (+), Jeremy Stanley wrote:
[...]
> I've determined that (for reasons as of yet unknown) this is only
> happening in one of our two providers, so I'm temporarily removing
> the problem nodes while I continue to debug this. Hopefully that
>
in advance
this time, and probably do an early enough cut-off for the sign-up
sheet that I (or someone, or everyone) can print out copies before
leaving home rather than trying to arrange for printing services at
the conference.
--
Jeremy Stanley
signature.asc
Desc
hen requests to do something more formal sprang up
shortly beforehand, I ended up making a course correction with
little time for proper planning. We can, and will, do better!
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.opensta
th their own key
fingerprints because they don't (yet) operate in circles where
keysigning is commonplace. There are much better methods for
high-volume KSPs (Clint links to my favorites in his message later
in the thread, so I won't) and we should use one of those thi
up leaving out people who might be doing
those things instead...
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
watch
list for anyone who spends time mentoring new contributors, so that
we can be sure to keep it up to date and relevant.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/list
can propose a session for this purpose, but there's no expectation
it'll be approved (at which point we have even less time to consider
alternative solutions).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
ht
for project renames,
but tend to make exceptions for any sort of pasta.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 2014-04-09 10:49:20 -0700 (-0700), Clint Byrum wrote:
> Excerpts from Ruslan Kamaldinov's message of 2014-04-09 10:24:48 -0700:
> > But, other concerns were expressed in the past. Let me quote
> > Jeremy Stanley (from https://review.openstack.org/#/c/66884/):
> &
On 2014-04-16 09:30:45 +1200 (+1200), Robert Collins wrote:
> Redhat offered to host the next TripleO midcycle meetup in Raleigh,
[...]
Neat--I live in that town! We definitely need more OpenStack
happening in it. ;)
--
Jeremy Stanley
___
OpenSt
from it with something like...
ssh-keygen -p -f ~/.ssh/id_dsa
(enter the old passphrase when prompted, and just don't enter
anything when prompted for a new passphrase)
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.opens
On 2014-04-15 23:24:31 + (+), Jeremy Stanley wrote:
[...]
> You'll need to strip the encryption from it with something like...
>
> ssh-keygen -p -f ~/.ssh/id_dsa
[...]
Or more likely, since the patents on RSA expired about 14 years
ago...
ssh-keygen -p -f
ck.org/37461 (so I don't think
it's entirely fair to assert that "OpenStack doesn’t pin requests
because...extraordinarily stable").
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.ope
indefinitely left in Gerrit with "workflow -1" set any different
from a change indefinitely left in Gerrit with "abandoned" set? It's
not like we go through and purge changes from Gerrit based on these,
and they take up just as
use of it. I think it would have been more
friendly to our community if the people who were no longer
interested in maintaining that feature had explicitly removed it
instead... but then it sounds like you would assert that having the
machine abandon this feature for us was less likely to offend
anyone
On 2014-09-16 21:42:49 + (+), Jeremy Stanley wrote:
> The project infrastructure team will be taking the Gerrit service on
> review.openstack.org offline briefly from 20:30 to 21:00 UTC this
> Friday, September 19 in an effort to move the newly-approved Shared
> File Sys
duration as well, since the
stable server releases will continue needing to use them.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ff--mildly hypocritical of us, I
know).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
discussing release schedules. The foundation has to negotiate
contracts on facilities/hotels a year or more in advance.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
onsider some old
habits that need changing such as tight coupling to the internal
APIs and implementation details of other projects... especially if
doing so lets us scale back our integration testing, rather than
leaning on it harder so that these undesirable development patterns
can continue unabated.
On 2014-09-26 08:34:48 -0700 (-0700), James E. Blair wrote:
> I'm pleased to nominate Anito Kuno to the project-config core team.
[...]
Wholeheartedly seconded--I am very much in favor of having more help
from Anita on that project.
--
Jeremy Stanley
signature.asc
Description:
On 2014-09-26 08:35:02 -0700 (-0700), James E. Blair wrote:
> I'm pleased to nominate Andreas Jaeger to the project-config core
> team.
[...]
Yes, please! I'd be thrilled for Andreas to help us further on that
project.
--
Jeremy Stanley
signature.asc
Description: D
On 2014-09-26 08:35:18 -0700 (-0700), James E. Blair wrote:
> I'm pleased to nominate Sean Dague to the project-config core
> team.
[...]
What, he wasn't in it already? ;)
I'm thrilled for Sean to help with core reviewing duties on that
project if he's willing.
--
Jere
d just be honest about that and just
> give things a real version. Version numbers are cheap.
"Release early. Release often. And listen to your customers." -ESR
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
all in sync in the requirements lists."
But now think about how we're trying to make some of the projects we
develop more broadly usable outside of OpenStack... just last week I
noticed that one of our transitive dependencies uses pbr, and is
not bound to the same version restrictions as d
in roughly 12 hours once I'm reasonably
confident the maintenance activity poses no further risk to these
systems and have given then a cursory health check to make sure
nothing's seriously broken prior to heading into the work week.
--
Jeremy Stanley
signature.asc
Description: Digital
On 2014-09-28 14:44:20 + (+), Jeremy Stanley wrote:
[...]
> I will follow up again in roughly 12 hours once I'm reasonably
> confident the maintenance activity poses no further risk to these
> systems and have given then a cursory health check to make sure
> nothing
http://lists.openstack.org/pipermail/openstack-dev/2014-September/047252.html
[3]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/047253.html
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
OpenStac
. Though I
expect this would break horribly as we've no doubt got unversioned
transitive dependencies (so not under our control, unlike direct
dependencies) where the earliest releases were unusable.
--
Jeremy Stanley
___
OpenStack-dev mailing list
Ope
often than not, a merge commit), and mapping that
back to a change in Gerrit is nontrivial.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t summit.
Aww, and I was all set to pack a bottle of my special barbecue sauce
made from crushed fairies.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
seen StackForge project needs as a valid
justification for changes to official OpenStack requirements.
Perhaps this is an indication that murano-dashboard needs to join an
official program?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@
stead of jmulsow. If there's nothing there at all, then click into
the blank space and (carefully since it can't be changed later)
enter whatever you want it to be.
--
Jeremy Stanley
signature.asc
Description: Digital signature
___
On 2014-09-30 01:38:29 + (+), Jeremy Stanley wrote:
[...]
> the tips of these branches have been tagged "havana-eol" in
> preparation for branch deletion. The list of affected Git
> repositories is as follows:
>
> openstack-dev/devstack
> openstack
hey go EOL.
No need to mirror them. The final commit to the stable/havana branch
is tagged havana-eol prior to deletion, as my announcement a couple
weeks ago mentioned. This preserves the commit history indefinitely,
so you can always create a local branch from that i
sql_user001:th-mysql:
[...]
That's a third-party testing system reporting on those changes, not
run by the OpenStack project. I will however bring it to the
immediate attention of the operators at Rackspace maintaining the
"DB Datasets CI" (formerly "turb
ches to
get it back into working order.
[1] http://code.google.com/p/gerrit/issues/detail?id=561
[2]
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/manifests/gerrit.pp#n78
[3] http://rss.cdn.openstack.org/nova.xml
--
f maintaining special 3.3 test infrastructure.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
://launchpad.net/bugs/1382582 to track
this. Thanks for any assistance you're able to provide!
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
hash seed, but also
can't run under a different hash algorithm), and properly fixing one
will fix the other. Unfortunately there isn't an easy workaround for
the Python 3.4 testing issue, unlike bug 1348818.
--
Jeremy Stanley
___
OpenStack-d
so we probably wouldn't want
to duplicate that exactly, but perhaps something more lightweight
would be a reasonable compromise.
Anyway, I consider it a good feature request (others may disagree),
just nobody's reimplemented it in nodepool to
infra/system-config'
where name='openstack-infra/config'"
sqlite3 ~/.gertty.db "update change
set id = replace(
id, 'openstack-infra%2Fconfig',
'openstack-infra%2Fsystem-config')
e rest of
> openstack docs.
[...]
Well, actually that's still in progress. The last bit we need is to
host a redirect somewhere so that devstack.org/(.*) is 301'd to
docs.openstack.org/developer/devstack/$1 instead, and then we change
the DNS address records to point to wherever we
nto requirements enforcement.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 2014-10-21 17:00:09 + (+), Jeremy Stanley wrote:
> Well, actually that's still in progress. The last bit we need is to
> host a redirect somewhere so that devstack.org/(.*) is 301'd to
> docs.openstack.org/developer/devstack/$1 instead, and then we change
> the
I
don't think has been settled quite yet).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
just don't happen to have anything like
that on hand currently.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> could not see an easy way to provide feedback from this page.
Perhaps a link to https://www.openstack.org/user-survey from there
would be appropriate?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.op
rticipate as I was spending too much time focusing the equipment
and attempting to hold it steady (leaving me little time to
cross-check participants on the list myself). With an upright unit,
I suspect we can operate the line in more of a self-service fashion.
--
Jerem
s
requisite fingerprint list to follow some process as a group, for
example http://keysigning.org/methods/sassaman-projected
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
d remain unmanned while people set documents on
the table for it to display. It's what us old kids used to call an
"overhead projector."
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.
45582d7e3e7f#.VFEaM_msV8E
Also, Infra/QA/RCM are sharing a workspace all Friday if you're
planning to be around... I expect these sorts of topics could weigh
heavily in choosing what we start work on that day.
--
Jeremy Stanley
___
OpenStack
ust needed to get to the point where we had two years worth of
board elections in the first place).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
hat you're saying. To mitigate we should
force new releases of all dependent clients/libs immediately prior
to dropping Python 2.6 support too.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.ope
ing for ideas on how our community might attempt to implement
something similar.
[1] https://lists.debian.org/debian-vote/2014/10/msg00281.html
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/
This not only makes for a stronger web of trust, but also a stronger
community in general. However, it's not strictly necessary to have a
time organized across the entire project to engage one another in
intimate groups.
--
Jeremy Stanley
_
our private key" lesson during the Hushmail incident of 2007. I
fear keybase.io is doomed to repeat that unfortunate bit of history.
For anyone who wants to find my public key, it's already in the SKS
pool and replicated to most other popular keyserver networks replete
with accumulat
before the TC.
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
waxing poetic, and yes there is no shortage of people who are
"stupid on the Internet" (I'll readily acknowledge that I'm one of
them from time to time). Chalk it up to me being bitter ever since
the start of Eternal September.
--
Jeremy Stanley
___
e and maintain stable backport branches as needed,
makes the problem much more tractable in the long term.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e.
[...]
As a counterargument, some Oslo libs have grown stable branches for
security backports and cut corresponding point releases on an
as-needed basis so as to avoid introducing new features in stable
server deployments.
--
Jeremy Stanley
___
O
development, should not depend on features only
available in unreleased versions of libraries.
> But in latest update of stack.sh, it’s to use pip by default
[...]
And this is intentional, implemented specifically so that we can
keep it from happening aga
of our software because our tests
*are* part of our software.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 2014-11-14 08:31:37 -0500 (-0500), Donald Stufft wrote:
[...]
> with TLS you depend on the web server to not be compromised
[...]
Or in some cases, the CDN. ;)
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
h
ow that the
publication job is live (assuming I wasn't completely off the rails
when I wrote it).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rtificate pinning rather than trusting any old CA (after all,
they're not Web browsers, so they could in theory do that with
minimal impact).
Too bad https://github.com/pypa/pip/issues/1168 hasn't gotten much
traction.
--
Jeremy Stanley
___
OpenSta
tep is required.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ithub.com/testing-cabal/testtools/issues/121 in case any of
the cabal stuck around for the weekend to keep an eye on things.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
In older* versions it just
populated the categorized articles list at the category page URL but
was otherwise undecorated until you added content.
[*] no idea how long ago that was since I've been using MW for more
than a decade and haven't set up new categories fo
ckages in
devstack:
https://review.openstack.org/#/q/Ib0e27fd,n,z
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s of
testtools and unittest2 then presumably your distro has pre-selected
versions of them which are known to interoperate?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ck+tempest jobs install devstack/server requirements globally
on the system but then tempest requirements are installed separately
into a virtualenv?
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.o
> I like that.
Honestly I don't, but it sucks less than the other solutions which
sprang to mind. Hopefully someone will come along with a more
elegant suggestion... in the meantime I don't see any obvious
reasons why it wouldn
On 2014-11-16 13:51:07 -0500 (-0500), David Shrewsbury wrote:
> I like Blaze Bearly, lead singer for Ironic Maiden. :)
[...]
Ironically, it works on too many levels.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.
On 2014-11-17 16:41:02 -0800 (-0800), Joshua Harlow wrote:
> Robert Collins wrote:
> [...]
> >That said, making requirements be capped and auto adjust upwards would
> >be extremely useful IMO, but its a chunk of work;
> > - we need the transitive dependencies listed, not just direct dependencies
>
eviewers to look at the changes they *want* to see, not tell them
which changes they're *supposed* to review.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
job-builder project core reviewer team.
Their knowledge of the project internals and support of its existing
core reviewers has been invaluable.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.
s into the "documentation tools" description in
https://wiki.debian.org/DebianBootstrap#Circular_dependencies.2Fstaged_builds
so might be a good fit.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://
hich has
Python 3.2 as its default interpreter (not 2.7 or 2.6) is rapidly
shrinking... outdated releases of Arch Linux maybe? I can't think of
many other places that might be an issue honestly.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenSta
testing proposed patches merged to their target branches
for years...
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
iewers than post-release change approval, and
the easiest way to enforce this is through Gerrit ACL matches on
different git ref patterns for their respective target branches.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.opensta
pagate to our
official mirrors (you may have to manually remove any local tracking
branches you've created, but that shouldn't be much of a concern).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lis
es the number of branches
we're deleting per cycle now.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/git_review-1.24-py2-none-any.whl
>
md5sum: 4bb6b9c7042120d508e13ff0abe52e87
sha256: 8fa88ce99c50de1509e2b7944cb5272a91d3c354eacffc9aed9641af15b1d6d0
A huge thank-you to everyone who contributed!
--
Jeremy Stanley
signature.asc
Descrip
if our typical response to our inability as a project to
successfully test our code is to just keep writing more code and
rechecking over and over rather than pitching in on fixing the bugs
which impede testing, there may be no hope after all.
--
Jeremy S
eventing
further replication of that repository from Gerrit to GitHub. The
situation is being tracked in https://launchpad.net/bugs/1337735 .
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org
the python-dbus authors to get a
pip-installable package released to PyPI, so that it can be included
in the tox virtualenv (though for DevStack we'd still want to use
distro packages instead of PyPI, I think).
--
Jeremy Stanley
__
201 - 300 of 1706 matches
Mail list logo