Thierry Carrez wrote:
> At the Design Summit last week we discussed the Juno release schedule
> and came up with the following proposal:
>
> https://wiki.openstack.org/wiki/Juno_Release_Schedule
>
> The main reported issue with it is the presence of the US labor day
> weeke
name" is actually defined in programs.yaml:
http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml
It generally matches the name of the main project, but could potentially
be different, in corner cases.
--
Thierry Carrez (ttx)
_
n of the client should work with all previous versions of the
server. Therefore there is no "havana release" of the client, they
follow semver versioning on a single release channel.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStac
you think of "networking" as a theme. If the teams
converge, yes it makes sense. If they don't, we should just create a new
program. They are cheap and should reflect how we work, not the other
way around.
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signa
designating the grouping instead... I think that
would create more confusion that it solves. History in OpenStack proved
that when we reuse terms ("core" anyone ?) we end up with mess that
can't be easily untangled. I'd rather deprecate the use of the "project"
term n
development-focused mailing-list, to discuss the future of
OpenStack. Your question might get to a more appropriate audience if it
was asked on the OpenStack general mailing-list, which is focused on
questions about USING OpenStack today:
https://wiki.openstack.org/wiki/Mailing_Lists
Cheers,
--
Th
eaches our global-requirements.txt.
That sounds like a good item in our requirements review checklist. At
the design summit we talked about including requirements rules and
review tips as a living document within the requirements repo itself.
That rule would definitely fit in
mid-cycle meetup), so if you have one set up and participation is still
open, please add it there !
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nstack.org/wiki/Sprints it shows that this would be a
Nova+Ironic thing, and there is a TripleO+Ironic thing in Raleigh over
the same dates.
Should one of those drop its Ironic focus to encourage convergence of
Ironic devs on a single area ?
cheers,
--
Thie
Ruslan Kamaldinov wrote:
> Hi community and TC members!
> [...]
Please only follow-up on -dev! This shall keep this thread consistent.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.opensta
ify" under their own, independent,
non-OpenStack program. I don't think us using that terminology would
prevent them from doing that anyway. As long as the board makes sure the
trademark is not abused in such 3rd-party "certification" programs, I
think we are ok...
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Raleigh, North Carolina
Please update:
https://wiki.openstack.org/wiki/Sprints
with that info!
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s Murano end up providing ? Could you
elaborate on the "composition" mission ?
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
: https://review.openstack.org/#/c/99432
Looks good!
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
did I'd expect them to be aligned
>> with stable releases.
>>
>> Right now, I think they'd just be as-needed - if there's enough
>> backported to the stable branch to warrant a release, we just cut one.
>
> That's pretty much what I thought, too. We should
ps://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z
> [2]
> https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.opensta
ol so we can isolate from network effects before we can make
> this job gating again.
+1ed
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Mark McLoughlin wrote:
> On Thu, 2014-06-12 at 12:09 +0200, Thierry Carrez wrote:
>> Doug Hellmann wrote:
>>> On Tue, Jun 10, 2014 at 5:19 PM, Mark McLoughlin wrote:
>>>> On Tue, 2014-06-10 at 12:24 -0400, Doug Hellmann wrote:
>>>> [...]
>>>&
ote that in all cases (whether we follow
Thomas suggestion or not), the Debian *binary* package will be named
"python-bash8", which is apparently what you don't like. That's not
because "a random set of developers is forcing upstream", that's due to
Debian&#
ny subcategories in "other", I would
not have any subcategory there and just lump them all in the same
category. That's about as relevant as lumping all integrated projects
work into the same "integrated" category, anyway.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
er the level where they become a problem.
You can't just have a specific process that kicks in when "the gate
queue gets a race".
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ed) when you have a captive set of developers just can't
work in our open development setting. Some techniques which work
perfectly for a release-oriented product just don't cut it when you also
want the software to be consumable in a continuous delivery fashion. We
certainly can and
ze where changing style rules is just too
costly, whatever the moment in the cycle. I think it's good that we have
rules to enforce a minimum of common style, but the added value of those
extra rules is limited, while their impact on the common gate grows as
we add more projects.
--
Thi
the first part of Anita's draft captures that very well, so
maybe that's all we need. I really think that documenting and better
communicating expectations will actually avoid problems in the future.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
1s could be +2/APRVed directly by a core reviewer.
That would slightly reduce load on core reviewers, although I suspect
most of the time is spent on complex patches, and trivial patches do not
take that much time to process (or could even be seen as a nice break
from more complex patch reviewing).
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
example above, that we could
substitute a Trove resource to the mysql package ? or put a Neutron
LBaaS load balancer on top ? or publish a DNS entry via Designate ?
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.op
idering moving all client projects under a specific client
tools program though, so having a way to analyze their behavior
separately surely will help as a data point.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/openstack/neutron/tree/milestone-proposed
https://github.com/openstack/cinder/tree/milestone-proposed
https://github.com/openstack/heat/tree/milestone-proposed
https://github.com/openstack/trove/tree/milestone-proposed
Regards,
--
Thierry Carrez (ttx
Thierry Carrez wrote:
> We just hit feature freeze, so please do not approve changes that add
> features or new configuration options unless those have been granted a
> feature freeze exception.
>
> This is also string freeze, so you should avoid changing translatable
> strin
am have the same core
review team. So you could have different core reviewers for both
(although I'd encourage the core for ones become core for the other,
since it will facilitate behaving like a coherent team). You could also
have a single core team with clear expectations set ("do not app
fit of having this IN the release (rather than early in
tree in Juno) is not really obvious. We already have a significant
number of FFEs lined up for Nova, so I'd be -1 on this one.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
sadly that is not part of the
> scope at the moment.
Sounds self-contained enough... but we have a lot piled up for Nova
already. I'm +0 on this one, if Nova PTL wants it and it lands early
enough to limit the distraction, I guess it's fine.
--
Thierry Carrez (ttx)
has gone through functional testing with our internal QA team
>
> ndipanov has been good enough to say he will review the patch, so we would
> ask for one additional core sponsor for this FFE.
This one borders on the bug side, so if it merges early e
t
think it should be Climate's responsibility to specifically maintain
spot price, everyone can come up with their own rules.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
's a net gain. If not, it becomes too
much of a distraction from bugfixes for reviewers and any regression it
creates might get overlooked.
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing lis
Avishay Traeger wrote:
>
> Avishay Traeger is prepared for DELETION (FREEZE)
Wow. Scary.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
blogpost[2]. Remember that the deeper we go into
the freeze, the less likely it is for *any* FFE to be granted or extended.
[1] https://launchpad.net/~openstack-release/+members
[2] http://fnords.wordpress.com/2014/03/06/why-we-do-feature-freeze/
Thanks everyone !
--
Thierry C
ose with Steve Baker yesterday. I'm fine with this but they
really need to make it in before Tuesday, since it's a significant
feature and I would like it to see some mileage. So +1 as long as you
can merge them fast.
--
Thierry Carrez (ttx)
Flavio Percoco wrote:
> On 06/03/14 11:50 +0100, Thierry Carrez wrote:
>> So on one hand this is a significant change that looks like it could
>> wait (little direct feature gain). On the other we have oslo.messaging
>> being adopted in a lot of projects, and we reduce the ma
we can appropriately set
> expectations with the community and customers.
The reference list lives in the governance git repository:
http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml
--
Thierry Carrez (ttx)
__
quot; advice request than a formal incubation request.
These are interesting questions, and useful answers to projects. We (the
TC) may need an avenue for projects to request such feedback without
necessarily engaging in a formal incubation request.
be merged with.
More information about the Juno Design Summit can be found at:
https://wiki.openstack.org/wiki/Summit
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Sergey Lukjanov wrote:
> thanks for opening sessions suggestions for Design Summit. Could you,
> please, rename Savanna topic to "Sahara (ex. Savanna)"?
Done!
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lis
your
experimentation. We definitely need to improve in this area. I'd like to
have a cross-project session on feature planning/tracking at the Design
Summit, where we can brainstorm more ideas around this.
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s been requested in the past. Feel free to propose a patch.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
gratuitous change) and (2) need a mechanism in place to warn translators
about that late change (that could just be a ML post).
That way we make sure that if a string gets changed, it's worth the
hassle it creates and the relevant people know about it.
--
Thierry Carrez (ttx)
all the things
together (which is its main feature).
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Launchpad bugs can have
tasks affecting multiple projects). So if this idea sticks, it would be
nice to have a solution for approval of cross-project specs in the future.
In the mean time this is not a blocker to experimentation.
--
Thierry Carrez (ttx)
_
st saying
that in order to be useful, it needs to be as minimal as possible (both
in amount of code written and code imported) and as simple as possible
(so that its security model can be easily proven safe).
--
Thierry Carrez (ttx)
___
Open
certainly looks promising enough to do a more complete
proof-of-concept around it. This adds packaging complexity and we are
likely to have only a subset of features available, but it may still be
worth it.
I filed the following session so that we can discuss it at the summit:
http
imary goal.
It may impact packagers in some corner cases so I'd engage with them to
check (#openstack-packaging ?) *and*, like Doug recommends, wait for
after icehouse release to make the change.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing
That said, the devil is in the details... There are bugs best fixed by
adding a library dep, there are version bumps, there are Oslo
libraries... I've added this topic for discussion at the Project/release
meeting today (21:00 UTC) so that we can hash out the details.
--
Thierry Carrez (ttx)
raging specific
branches of openstack/requirements to ensure nothing inadvertently slips in.
That said, given that feature freeze is in progress I don't expect new
dependencies to be added at this point anyway.
--
Thierry Carrez (ttx)
___
OpenSta
he integrated release so that we don't add (even
temporary) divergence. If the answer is "definitely no", then we'll have
to choose between convergence and functionality.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStac
e.
Personally I don't consider "serving the internal needs of OpenStack" as
a feature blocker. It would be nice if it could, but the IaaS+ use case
is IMHO compelling enough.
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
__
damage of reverting CD followers to pre-October
behavior...
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rn. The question then becomes,
how usable this SQLA option actually is ? If it's sluggish, unusable in
production or if it doesn't fully support the proposed Marconi API, then
I think we still have that concern.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
orever and this is just the
wrong timing to rush a new implementation to fix it.
I filed a rootwrap session for the Juno Design summit -- ideally we'll
have various solutions ready by then and we'd make the final choice for
early integration in Juno, leaving plenty of time to catch the we
benchmark is affecting numbers. Could you post
results from a realistic setup (like same command, but with all the
filter files normally found on a devstack host ?)
Thanks,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
all
odds because of Sergey's "presence" in horizontal programs like Infra.
Let's all make the best of this additional incubation cycle to all get
more comfortable with each other :)
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
___
ll goes to reverting, for all the reasons Chris just exposed.
I could live with the middle road though... My main concern is to avoid
breaking release followers with an issue we detected pre-release.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rap is not
the end, it's just the beginning.
As a final note, the best solution is not "better rootwrap filters". the
best solution is solid design that doesn't require running anything as
root. So components without run_as_root calls should really stay that
way. And compone
that point we'll create a milestone-proposed branch for
openstack/requirements itself and unfreeze the master branch for Juno
improvements.
Thanks,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.op
> mockito https://review.openstack.org/#/c/80850/
This one was abandoned. Trove team is "looking to move away from mockito
to mock. Timeline is in the next 4-5 days".
> wsgi_intercept https://review.openstack.org/#/c/80851/
This one was merged.
--
Thierry Carrez (ttx)
__
ately related to
the same "story".
So feature stories in StoryBoard can definitely have, as their first
task, a "design" task that will be linked to a change to a -specs
repository. Then when the design is approved you can add more tasks to
that same story, corresponding to im
"use_syslog_rfc_format" config option to honor RFC5424
https://bugs.launchpad.net/oslo/+bug/904307
Fix IpFilter so that it can't be trivially bypassed
https://bugs.launchpad.net/oslo/+bug/1081795
Regards,
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP di
think next week is fine :)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or adventurous projects in the K cycle.
So it's not vaporware, it exists for real. But there is still a lot of
work needed on it to be generally usable, so it shouldn't be used as an
argument to stall everything else.
--
Thierry Carrez (ttx)
___
and announced
8. Deprecation messages are added to code for API vN users
9. At removal date, API vN is removed
Keystone is at step 4. It shouldn't use "deprecation" terminology before
step 6.
If step 4 is blocked, project should first raise the issue at
cross-project meetings, a
Prince
> Dave Walker
> Gabriel Hurley
> Joe Heck
> Eric Windisch
>
> If any of you wish to remain on the core reviewer list during Juno,
> speak up. Otherwise we'll purge the list around the time of the
> dependency freeze (Thierry, let me kn
ted, but it's not done yet.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.
Note that the "master" branch of Keystone is now open for Juno
development, and feature freeze restrictions no longer apply there.
Regards,
--
Thie
Sergey Lukjanov wrote:
> NOTE: It's approved now.
Yes, I just approved it. Note that it also contains an important
security fix (see OSSA-2014-007 just published).
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenS
uot;master" branch of Cinder is now open for Juno
development, and feature freeze restrictions no longer apply there.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/
.4,!=0.6,!=0.7", *if*
Ceilometer folks confirm that 0.8 is fine by them. That way distros that
are stuck with 0.5 are not otherwise adversely affected.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://l
avoid
> confusion as we don't expect every approved blueprint to get implemented.
Great idea.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reminder: This is the *last* day for ATCs to use their Atlanta summit
registration discount:
Original message
Sujet: [Openstack] ATC Reminder: Summit Registration
Date : Fri, 28 Mar 2014 08:43:02 -0500
De :Claire Massey
Hi everyone,
Just a quick reminder that registratio
Thierry Carrez wrote:
> Julien Danjou wrote:
>> On Thu, Mar 27 2014, Thomas Goirand wrote:
>>
>>> -happybase>=0.4,<=0.6
>>> +happybase>=0.8
>>
>> Good for me, and Ceilometer is the only one using happybase as far as I
>> know so
"happybase>=0.4,!=0.6,!=0.7" as it allows 0.8
to be run without adversely impacting downstreams who don't have it
available.
--
Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
___
OpenSt
t;=0.5,!=0.6,!=0.7", so now
I'm confused. Since I think you updated the commit title and failed to
update the requirements file, I'll wait a bit before approving.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@l
://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit
> to discover that that wiki page does not yet exist and I do not have
> permission to create it.
Err... anyone can create anything on the wiki. Maybe you weren't logged in ?
--
Thierry Carrez (ttx)
_
on how to best fit it into the schedule?
> ...hopefully not wedged into a restroom break like I ended up doing
> last time. ;)
No miracle here... All slots are pretty full as expected. I think our
best bet is still the 30-min morning break on Wednesday or Thursday at
10:30am.
--
Thierry Carre
sier to produce
and test, and OSSAs are easier to review and publish.
Thanks for your consideration !
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thierry Carrez wrote:
> We have two *new* categories this time around:
>
> "Cross-project workshops"
> Those will be used to discuss topics which affect all OpenStack
> projects, and therefore increase convergence and collaboration across
> program barriers.
>
>
://bugs.launchpad.net/horizon/+filebug
and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.
Note that the "master" branches of Ceilometer and Horizon are now open
for Juno development, and feature freeze restrictions no longer apply there.
Regards,
--
er" branch of Nova is now open for Juno
development, and feature freeze restrictions no longer apply there.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/m
nt, and feature freeze restrictions no longer apply there.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
it to the release crew's
attention.
Note that the "master" branch of Neutron is now open for Juno
development, and feature freeze restrictions no longer apply there.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing lis
restrictions no longer apply there. All
integrated projects except Trove and Swift have now published their
first Icehouse release candidates.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.op
tions no longer apply there.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
/milestone-proposed
If you find an issue that could be considered release-critical, please
file it at:
https://bugs.launchpad.net/swift/+filebug
and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.
Regards,
--
Thierry Carrez
ntion.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
x27;s
attention.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
naming processes in
the past... so this should really be seen as the last solution. It's
also a pain for infra (repo renames) and developers who need to push the
package rename down all projects.
That said, if we are to do it, better do it at the start of Juno before
we graduate new libraries.
release candidate respin, please file it at:
https://bugs.launchpad.net/horizon/+filebug
https://bugs.launchpad.net/ceilometer/+filebug
and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.
Regards,
--
Thierry Carrez
age them to change their own passwords and
expire existing tokens (secondary key material).
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
---
You should file it at summit.openstack.org so that it can be considered
for inclusion in the schedule.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-potential* to bring it to the release crew's
attention.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
crew's
attention.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
this point, only Glance has a RC window opened (to produce a RC2) --
it's expected to be closed sometimes today.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-b
301 - 400 of 2055 matches
Mail list logo
