ng it manually).
Unless perhaps you're suggesting that we should allow approved
changes to merge even with a workflow -2 from another reviewer
(keeping in mind that we don't currently allow changes with a
workflow -1 to merge).
--
Jeremy Stanley
ar.gz to
> http://libvirt.org/sources/ ? Using the latest release seems
> better than master from git.
[...]
Would getting it into EPEL for CentOS 7 or UCA for Ubuntu 14.04 LTS
hopefully be an option?
--
Jeremy Stanley
___
OpenStack-dev mailing list
O
n clear it
> when RC1 is published.
>
> Not sure that's supported in Gerrit though :)
As far as I know it's not... otherwise we'd have made WIP do the
same as you describe.
--
Jeremy Stanley
___
OpenStack-dev mai
developers and deployers to
use into Ubuntu 14.04 Cloud Archive and CentOS (RHEL) 7 EPEL on the
other hand would be a much more viable long-term solution.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
moving the problem--each additional
mirroring solution is something new we have to monitor, maintain and
troubleshoot so we must ask ourselves whether the increased
management burden from that new complexity is balanced by potential
decreases in management burden found by improving stability in other
par
mirror for a handful of files. It's worth adding to
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
and discussing tomorrow, if you're around, so we can be sure to
get input from more of the Infra team.
--
Jeremy Stanley
___
re willing to support
an untested feature through deprecation or insist on continued
testing until its full removal can be realized.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
do
so from within your system rather than trying to trigger it by
leaving unnecessary review comments on lots of changes.
[1] https://launchpad.net/bug/1355480
[2] https://review.openstack.org/109565
[3] http://lists.openstack.org/pipermail/openstack-infra/2014-A
ow. Thanks for
the rapid response when it was brought to your attention!
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
bilities).
Having something similar when I need to get in touch with a project
about an infrastructure-related task instead would be equally
convenient.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.open
t
individual projects supporting your drivers/features/whatever might.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
in
recent history) time we replaced the Gerrit SSH API RSA host key on
review.openstack.org was in April as a safety precaution in the wake
of the Heartbleed Bug announcement. We definitely haven't touched it
in the four months since then.
--
ciously or not) promote the use of proprietary solutions to your
needs rather than embracing less convenient free and open options
which may still require improvement.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http:
nse to revisit why we
have those additional pipelines and instead focus on resolving the
underlying issues which led to their use as a stop-gap.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/c
ew bugs
cropping up to take their place once those are solved/worked around,
but at least the current state is not entirely due to the volume and
duration of jobs we run.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.op
lusion into an official project. Pretty sure that
counts as one of the reasons we maintain that whole rig. ;)
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Now I will believe that there are unicorns!
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that particular job.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
no
reason to be using our mirror for YOUR systems. If you're not
running a PyPI mirror of your own, you should just use
pypi.python.org instead.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstac
On 2014-08-17 23:53:12 -0700 (-0700), daya kamath wrote:
[...]
> openstack-infra does not get updated as part of the gate jobs
[...]
Right, we use puppet to continuously apply that configuration to our
durable workers and nodepool templates.
--
Jeremy Stan
n for both
and embed a parameter expansion in the template name which is unique
per project).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
terms
which make it apparent that there is nothing at all glamorous nor
powerful about the appointment.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
if
not. So if a third-party CI is encountering changes which really
can't be merged (rebased, cherry-picked, whatever) to the project
then they should refrain from commenting at all... at this point it
would be at best redundant, and at worst
loper trying to work out what to patch
where to make it not happen again (if you're lucky).
That is "gate debugging" and, to support your point, is something
which can at best be only vaguely documented.
--
Jeremy Stanley
___
OpenStac
id the Gearman integration for Zuul... however it's also an
option not to be taken lightly and comes with its own set of unique
challenges.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.
On 2014-08-27 16:53:39 -0700 (-0700), Clark Boylan wrote:
[...]
> I thought there was a wiki article on how they work but I can't
> find it. Maybe someone else can link it here.
[...]
https://wiki.openstack.org/wiki/GerritJenkinsGit#Merge_Commits
--
Jer
initely is a reason to just keep those
pieces in their own separate Git repositories outside of the core
Neutron repository in perpetuity (even after they "graduate" from
incubation). One package per repository. That should be chiseled in
stone
far as that (in some ideal world) it might
allow the reference L3 service plugin to be extracted from the main
tree and developed within a separate source code repository with its
own life cycle.
--
Jeremy Stanley
___
OpenStack-dev mailing lis
is
https://wiki.openstack.org/wiki/GerritJenkinsGit#Merge_Commits if
you're interested in how it's implemented.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
isn't
yet being used for any existing pipelines).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
3 jobs out for python34,
ready to drop once the j-3 milestone has been tagged and is finally
behind us.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
week to 2.
How about just automatically abandon any new change as soon
as it's published, and if the contributor really feels it's
important they'll unabandon it.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
ink ANSI escape sequences are a neat idea.
[...]
Well, you already had me with 80 columns, but I actually
[32;1mdo[0m think ANSI escape sequences are a neat idea.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://list
eam won't
> it?
Not all changes bring new features (I certainly hope many of them,
if not the majority, fix bugs instead). I'm in the "polish what we
have, no new features for a while" camp myself, but... um... you've
just proposed a new infrastructure feature. I'll assume from your
comment that you don't expect the Infra core team to maintain it.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
bably best to re-raise this question on the
legal-disc...@lists.openstack.org mailing list as well.
[1] http://dev.hasenj.org/post/3272592502/ibm-and-its-minions
[2] https://github.com/jshint/jshint/issues/1234
[3] http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html
--
as such:
> https://github.com/jshint/jshint/blob/master/LICENSE
Ahem. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19
> You are thinking of JSLint, which is written by Douglas Crockford.
JSHint is a derivative project of JSLint. Sorry to burst your
bub
speak to their plans and current progress
though.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
reaches end of support. So don't
get all excited that 2.6 is "going away entirely" in a couple
months.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
go back and fix the ones we did
before we noticed this unfortunate loss of date/time information.
This maintenance notification looks relevant...
http://lists.openstack.org/pipermail/openstack-dev/2012-December/003934.html
--
Jeremy Stanley
___
OpenStack
x27;: 'http://pypi.openstack.org/openstack',
[...]
> Could not find any downloads that satisfy the requirement Paste
[...]
You have your environment misconfigured to use a mirror of PyPI
which is no longer maintained. Please use pypi.python.org or a
mirror you mai
to the old one. We chose the first solution as it was
more directly under the control of the infrastructure and nova core
teams involved at that moment.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.open
m hash seed
randomization in newer tox releases would seem to contradict your
assertion. Also documentation...
https://docs.python.org/2.7/using/cmdline.html#envvar-PYTHONHASHSEED
(New in version 2.6.8.)
--
Jeremy Stanley
___
OpenStack-dev mailing list
Op
you have to pass -R to get that behavior) but you can
still totally override the hash seed from the environment in 2.x
(and more recent versions of tox happily do this for you and print
out the hash seed which was chosen for a given test run).
--
Jer
tch. Yes it does add some extra
time to the next test run, but you can iterate fairly tightly after
that as long as you're not actively moving stuff around while you
troubleshoot (and coupled with a git hook like Doug described for
cleaning on topic branch changes would be a huge boo
m, which
tools should create for you (it's normally generated by a Git hook
which is installed in your local repository configuration the first
time you run 'git review' and then gets inserted into commit
messages for you on each subsequent commit message edit in that
repository). Ple
ne or more of the OpenStack projects.
[...]
Sounds like an NP-complete problem, but if you manage to solve it
let me know and I'll turn it into the first line of triage for Infra
bugs. ;)
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-d
list of projects being moved is:
* stackforge/manila -> openstack/manila
* stackforge/python-manilaclient -> openstack/python-manilaclient
We'll follow up with a reply to this thread once the planned work is
complete.
--
Jeremy Stanley
signature.asc
Description: Digita
on code was excellent at
> doing this, but alas, it is no more.
I think it was excellent at arbitrarily abandoning open changes
which happened to meet a poorly-thought-out set of criteria. I'm
personally quite glad it broke and we didn't waste time
reimplementing something similar for ne
e referring. Sorry for the confusion!
--
Jeremy Stanley
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?su
On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
[...]
> Did I miss any options or issues with this approach?
https://review.openstack.org/578557
--
Jeremy Stanley
signature.asc
Description: PGP signat
On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote:
> Jeremy Stanley writes:
>
> > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> >> Did I miss any options or issues with this approach?
> >
> > https://review.openstack.or
lability of venues and other logistics.
--
Jeremy Stanley
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
aving to manage a test platform transition on a
stable branch.
--
Jeremy Stanley
signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-de
hour has elapsed from the #startmeeting. After an hour, anyone can
so I did an #endmeeting in your channel and it wrapped up and wrote
the minutes and logs as usual:
http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-11-07-14.16.html
--
Jeremy Stanley
signature.asc
f you're not careful to keep your branches clean.)
[*]
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config
[**] https://review.openstack.org/#/admin/groups/neutron-release
--
Jeremy Stanley
signature.asc
Description: PGP signature
_
are closed
down for good).
[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description: PGP
opics
Which is its initial location for crowd-sourcing/brainstorming, but
will get published to a more durable location like on
lists.openstack.org itself or perhaps the Project-Team Guide once
the list is in use.
--
Jeremy Stan
case either might be resulting in
subscribers missing it.
[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description: PGP sign
o them
over the next week.
[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
--
Jeremy Stanley
signature.asc
Description: PGP signature
__
OpenStack Development
or
no fewer than three addresses, sending several probes to each, and
be considered successful if at least one gets a response.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 2013-11-21 13:59:16 +0100 (+0100), Salvatore Orlando wrote:
[...]
> In its default configuration the traffic from the OS instance is
> SNATed and the SRC IP will be rewritten to an address in the
> neutron's public network range (172.24.4.224/28 by default). If
> the OS instance is trying to rea
results back on proposed changes:
http://ci.openstack.org/third_party.html
For a longer term solution, you may want to consult with the TripleO
project with regards to their bare-metal test plan:
https://wiki.openstack.org/wiki/TripleO/
.org/wiki/GerritJenkinsGithub#Merge_Commits >
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ed. I certainly don't want to introduce yet another
nondeterministic bug into our integrated gate tests, especially
after everything else we've been through in that regard this week.
--
Jeremy Stanley
___
OpenStack-dev mailing list
from developing this on a separate
branch as you would working inline on master and hiding feature
changes behind switches, so the added complexity here may not gain
you any real convenience.
--
Jeremy Stanley
___
OpenStack-dev mailing list
Open
On 2013-11-22 20:29:10 + (+), Jeremy Stanley wrote:
[...]
> At the moment, we're still looking for confirmation that
> nova-compute no longer locks up with the latest libvirt in UCA
> (1.1.1).
[...]
I emulated a full (parallel) tempest-devstack-vm-full run on several
fresh
key them on, but creating one every time it's needed might also
come across as makework (or maybe we recheck them all on bug
1021879, but then I worry that would skew our statistics gathering).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ke that, however, you'll need to provide your own place
to publish your logs (something like we use--bog standard Apache on
a public VM--should work fine I'd think?).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack
-l or rpm -qa at the
end of the job similar to how we currently already do a pip freeze.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 2013-11-28 06:46:27 -0500 (-0500), Yair Fried wrote:
[...]
> 4. Jeremy Stanley - "test check for no fewer than three addresses"
> -- Why?
If your tests try to communicate with addresses which are truly
outside your own network, and thus outside your sphere of control,
you
a standardized
location within each git repository (for convenience). Possibly
another pattern we should suggest following as part of any
application for incubation.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://
ation was
excellent, and I'm quite impressed to see the awesome things you're
doing with IPv6 and OpenStack (locally, no less!).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-b
doesn't look like this got lost in the list
noise) your https://review.openstack.org/59860 change you linked in
IRC seems to have been the actual cause of the observed failure.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
tied to the mirror, you will receive the commits. (It's the
> same thing, get it)
[...]
Also, Clark fixed[1] these (thanks!!!) so they will start getting
updates again. Correct ones this time, unless we're really, really
wrong about something there.
[1] https://review.openstack.org/
ecause not doing
so allows us to break ourselves in unfortunate ways.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, so we don't land changes to servers
which require unreleased client features.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be a welcome
contribution.
Any help we get dealing with already public vulnerabilities frees up
more of our time to focus on embargoed items while still keeping the
core group small (minimizing risk of premature disclosure). More
info at...
https://wiki.openstack.org/wiki/Vulnerability_Management
--
ill merge rather quickly if you decide to
revisit approving them before the Monday rush.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
orizon/+spec/django-1point6 and
pitch in on reviews, patches or discussions related to this work if
it is important to you.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
) to fix/workaround it here:
> [...]
>
> The bug to recheck against is 1263824.
Also, the fix is merged as of a few hours ago, so we shouldn't
expect any new recurrences.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.opensta
for filtering project
watches--the "Only if" field you see on the Watched Projects setting
page.
https://review.openstack.org/#/settings/projects
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http:/
ause some operators very well may be hamstrung by
cargo-cult "best practices" requirements like that baked into their
corporate security policies (so they'll need to be able to support
such schemes no matter how backward it might seem).
--
Jeremy Stanley
.8 or 2.9 the flexibility in the search interface may
increase significantly (I've heard it gives you the ability to
bookmark various searches as custom dashboard views, but not sure
what other search improvements may be added there).
--
Jeremy Stanley
___
#x27;s
a strict timeline or schedule for it at this point, but it is
definitely being worked on.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t ChangeLog autogenerated by PBR from the Git commit
log while others prefer to hand-curate their ChangeLog file instead.
The first project will want ChangeLog listed in .gitignore while the
second will want it to actually get checked into the repo.
--
Jer
t in
hopes of making this thread a little more visible to them.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ess as a culture. I see the
more recent "devops" movement as simply a return to the idea that
you run systems by writing and debugging software rather than
waiting for someone else to write/fix it for you.
--
Jeremy Stanley
___
OpenStack-dev mailing
n absolute
minimum... thus much testing is still outstanding even though we
think we've (mostly) ironed out the remaining issues.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ain in popularity, I hadn't associated
test-centric development culture with it. I can definitely see the
relationship though, and so concur it's a positive outcome (and not
merely a throwback to "the beforetime").
--
Jeremy Stanley
_
etaddr {opts} {packages}
The down-side is that anyone with earlier virtualenv installed will
need to upgrade to a version bundling pip 1.5 since pip before 1.5
the --allow-unverified option isn't recognized so pip exits nonzero
when tox tries to pass it in.
--
Jeremy Stanley
__
vstack-gate have been
invaluable.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
erfectly reasonable to suggest that as an alternative. It
is just one of the many ways a contributor avoids wasting reviewer
time by neither polluting their changes nor every project's
.gitignore with details potentially relevant only to thei
lying on them. We
similarly probably need to test changes for a library/client against
released versions of any other libraries or clients on which they
depend as well, for those same reasons.
--
Jeremy Stanley
___
OpenStack-dev mailing list
Op
tended
(which also means gaining confidence in the nuances of git's pattern
matcher).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ion
from the system (system-wide installs of old Jinja on CentOS 6 seems
like where nova ran into this).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Ubuntu Cloud Archive
again--hopefully someone will figure out what's wrong there soon so
we can actually start using UCA to get the bits we need for newer
PyPIfied MySQL-python to work for us).
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack
y (PBKDF2, bcrypt, scrypt, et cetera)?
MD5 is still resistant to preimage and second preimage attacks as
far as I've seen, and SHA256 doesn't take too many orders of
magnitude more operations to calculate than MD5.
--
Jeremy Stanley
___
O
hat already?
Not yet in any automated fashion but keep in mind that we've only
gotten the requirements update proposal job working reliably this
cycle, so it could still take some time for the various projects to
decide how to finish syncing
reviewday and
elastic-recheck, et cetera), so we need to keep plugging the hole
with workarounds there in the meantime.
--
Jeremy Stanley
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
1 - 100 of 1706 matches
Mail list logo
