tte
[2] https://wiki.openstack.org/wiki/ReviewChecklist
We can't really assume a common culture anymore, so documenting shared
understandings in our community is a critical step in maintaining
cohesion in our virtual and global community. This is a space we need to
work on in the near future -- t
eaning the spec needs to be approved and the code needs to be proposed
for review by then).
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rom
> Sean Dague goes into a bit of the background: [1]. The rest of this
> email outlines the medium and long-term changes we would like to make to
> address these problems.
> [...]
I like all the options suggested there, and I enjoyed the discussion
that followed.
--
Thierry Ca
yone have anything to add before I forward these to the TC?
When ready, propose a governance change a bit like this one:
https://github.com/openstack/governance/commit/52d9b4cf2f3ba9d0b757e16dc040a1c174e1d27e
Regards,
--
Thierry Carrez (ttx)
___
OpenS
; branches of their projects. They do not require global +2 for all stable
> branches though.
The key reason why $PROJECT-core don't automatically get stable branch
+2 is that the rules for accepting a patch there are VERY different from
the rules for accepting a patch for master, and most -core people don't
know those.
We need to ensure those -core people know the stable branch acceptance
rules before we grant them +2 there.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
enerally make good stable-maint
candidates). But that's not work they signed up for. I prefer that work
to be opt-in rather than add to the plate of core reviewers by making
them all collectively responsible for stable branch maintenance too.
Rules are
actually make it in time for release, rather than having to spend time
reviewing specs that have nearly no chance of being Juno material anyway.
So as far as TripleO goes, it really is a local team decision.
--
Thierry Carrez (ttx)
___
OpenStack-dev m
it gets forwarded) on the openstack general ML.
I'd expect you'd get extra data points from users from there.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Swartzlander, Ben wrote:
> On Tue, 2014-07-29 at 13:38 +0200, Thierry Carrez wrote:
>> Swartzlander, Ben a écrit :
>>> Manila has come a long way since we proposed it for incubation last autumn.
>>> Below are the formal requests.
>>>
>&g
;m not opposed to that, just saying that's an infra config change we
need to push.
I'm generally open to changing that, since I reckon we have a manpower
issue on the stable maint side. I just want to make sure everyone knows
what they are signing up for here. We would do it for al
ld avoid the above reconfiguration, but then the stable-maint
people have to check which +1s are actually $PROJECT-core +1s... which
sounds like a painful task.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.
#x27;t rush it. I'm pretty confident
oslo.rootwrap 1.3 (or 2.0) will be available by the Juno release, but
realistically I expect most projects to switch to using it during the
kilo cycle, rather than in the very last weeks of Juno...
--
Anne Gentle wrote:
> On Wed, Jul 30, 2014 at 7:22 AM, Thierry Carrez
>> The procedure for TC matters is the following:
>>
>> 1. create a thread on -dev so that we can all openly discuss the request
>> 2. make sure the TC notices the thread on -dev by posting a point
Jeremy Stanley wrote:
> On 2014-07-31 10:17:16 +0200 (+0200), Thierry Carrez wrote:
>> That's a good idea. We would probably switch to $PROJECT-stable-maint
>> teams then (each including $PROJECT-core and the general stable-maint
>> team) since we don't have a gr
gement" or even
"Operations" imho.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
part of its mission). If that position changed, merging the two sounds
good. The teams working on it are certainly mostly the same people anyway.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ecs.openstack.org/openstack/qa-specs/
>
> Thanks to Steve Martinelli and to the infra team (especially Clark,
> James, Jeremy and Sergey) for getting this done!
Nice work!
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@l
27;t bet my money on it -- I think
it might make sense to focus on reviewing stuff that is more likely to
make it (stuff that is already proposed for review) and have general
adoption of a Juno-released rootwrap daemon mode throughout all projects
during Kilo.
--
Thierry Carrez (ttx)
___
just explaining
where the tension comes from.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
eading this braindump this far. I hope this will trigger the
open discussions we need to have, as an open source project, to reach
the next level.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
lutions... Also be more integrated in OpenStack or part of the
OpenStack programs might come at a cost (slicing some functionality out
of rally to make it more a framework and less a product) that might not
be what its authors want.
Let's explore each option to see which ones are viable,
work on something else.
The solution is about setting release cycle goals and strongly
communicating that everything out of those goals is clearly priority 2.
Now I'm not saying this is a bad idea. Having too many reviews to
consider at the same time dilutes review att
projects (like if Nova disagreed with the
Neutron decision), then the issue could be escalated to the TC.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, that would just clearly express that this is not
ready to land for release cycle / organizational reasons.
Thoughts?
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nication that makes developers produce more / something else than
what core reviewers want to see. Any tool that lets us communicate
expectations better is welcome, and I think the runway approach is one
such tool, simple enough to understand.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
;t know how to fix it..
> Could you tell me some advice?
> Thanks a lot !!
This is not a development discussion, it's a usage/support question. To
get a better response, you should post it to the appropriate
mailing-list (openst...@lists.openstack.or
During
this exploration, Savanna devs may also decide that integration is very
costly and that their immediate time is better spent adding key
features, and drop from the incubation track. But in all cases,
incubation sounds like the right first step to get everyone around the
same table.
--
Thi
tone/1.9.3
Ideally, we should fix all the bugs in those lists (and publish RC1)
before the end of the month.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
ruption it would cause.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
but on the
other it's not really a self-contained feature and I could see it have
bugs (or worse, create regressions).
My answer would probably have been different if this request had been
posted a week ago, but at this point, I would lean towar
lzy@gmail.com wrote:
> On Thu, Sep 12, 2013 at 9:43 PM, Thierry Carrez wrote:
>> So, this is a significant feature... which paradoxically is a good
>> reason to accept it *and* to deny it. On one hand it would be nice to
>> complete this (with Glance support for it bein
2013
https://wiki.openstack.org/wiki/TC_Elections_Fall_2013
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jay Pipes wrote:
> [...]
> Any and all insight would be greatly appreciated.
Not really an insight, but looks like another occurrence of:
https://bugs.launchpad.net/ceilometer/+bug/1221580
--
Thierry Carrez (ttx)
___
OpenStack-dev mailin
n is minimal.
Could you quantify the performance issue, and address Zhi Yan Liu's
comments ?
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ates ML noise (which is a pain for
everyone).
Thanks,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
been annoying everyone about it in this
> list, though that's a very good thing).
Yes, Jeremy Stanley (fungi) talked about setting up a keysigning party
for the next design summit. Maybe you could coordinate with him.
--
Thierry Carrez (ttx)
_
That sounds like the simplest way to preserve behavior. From what you
said the current behavior is "try, fail and ignore failure" -- having
noop instead is probably the right thing to do for havana.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
cation is ineffective and creates ML noise (which is a pain for
everyone).
"""
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ss co-opted. Finally, I would like to reinforce program team
spirit: make it the work of a real group of people working together
rather than a loose collection of activities.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
veryone else is very welcome to attend.
The meeting will be held at 21:00 UTC on the #openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130924T21
See you there,
--
Thie
Robert Collins wrote:
> On 24 September 2013 20:08, Thierry Carrez wrote:
>> All Technical Leads for integrated programs should be present (if you
>> can't make it, please name a substitute on [1]). Other program leads and
>> everyone else is very welcome to attend.
>
01.673 | ERROR: could not install deps
>> [-r/home/jenkins/workspace/gate-nova-pep8/requirements.txt,
>> -r/home/jenkins/workspace/gate-nova-pep8/test-requi
>
> This seems to be an issue with pip not being able to find the right
> version of pyparsing. This is strange as the co
ple interested in
project management that could help in the PTL role and serve in a
succession strategy. So you shouldn't fear to piss of the established
PTL by challenging them :)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@
that specific weak chain link if another remains as
weak) to see where we can actually improve things significantly.
So I would wait for icehouse to do anything. If it's separated from the
core V3 API already, I guess it's still easy to get rid of it in
icehouse if that's the outc
teams in Launchpad. Those should have been unused for a few years
now, but i figured I would give everyone a heads-up before going into
this clean-up rampage.
I'll proceed in a few days if nobody objects to this plan.
--
Thierry Carrez (ttx)
___
Open
a thread on the ML (with proper subject),
and make sure the translations coordinators (Gabriel, Daisy) are aware
of it and can communicate the issue to their contributors.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists
nStack. You
should ask your question to the general openstack ML
(openst...@lists.openstack.org) which has the right topic and audience.
More information on mailing-lists @
https://wiki.openstack.org/wiki/Mailing_Lists
Regards,
--
Thierry Carre
Thierry Carrez wrote:
> Jeff Cai wrote:
>> I did all that the doc tells me to do, which includes
>> [...]
>
> Jeff:
>
> This sounds like a usage question / support request. The openstack-dev
> mailing-list is focused on development discussions for the future of
nd keeping them usable is critical to the
success of OpenStack. Respecting the topic for each list is the base
trick we use to keep the signal/noise ratio high. The next best thing is
to label the subject correctly.
Regards,
--
Thierry Carrez (ttx)
___
Ope
't take those into consideration yet...
Anita should add you and Liz to the Horizon PTL vote asap, sorry for the
inconvenience.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
d delay 2013.1.4 freeze (was planned this Thursday)
> until stable/grizzly is back in shape?
Given the gate slowness these days, RC1 being late and the advice not to
approve too much stable/* stuff, I think it makes sense to defer for at
least a week. Adam ?
--
Thierry Carrez
s and
everyone else is very welcome to attend.
The meeting will be held at 21:00 UTC on the #openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131001T21
See you there,
--
Thierry Carrez
eam takes it over.
Agreed. Actually making releases before applying for incubation is a
good idea. The only thing to watch is to avoid numbering your releases
above the openstack numbering (.i) so that when you get integrated
you don't need epoch tricks. Using 0.x, 1.x etc. is usually wor
er" branch of Keystone is now open for Icehouse
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/
the later it is visible, the less likely it is to
make it.
Reference:
https://wiki.openstack.org/wiki/Release_Cycle
Hope this helps,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/
there.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
is now open for Icehouse
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/mailman/listinfo/openstack-dev
Thierry Carrez wrote:
> Hello everyone,
>
> Last for today, the Ceilometer first release candidate for the Havana
> release was just published. 50 bugs were fixed since feature freeze 3
> weeks ago. RC1 is available for download at:
>
> https://launchpad.net/ceilome
rizon/+filebug
and tag it *havana-rc-potential* to bring it to the release crew's
attention.
Note that the "master" branches of Nova, Neutron, Heat and Horizon are
now open for Icehouse development, and feature freeze restrictions no
longer apply there.
Regards,
--
e a better way to
> figure that out, other than wading through hundreds of bugs?
The sooner the better, but they should be considered work in progress
until release time (Oct 17).
You can get a glimpse at:
http://status.openstack.org/release/
--
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
#openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131008T21
See you there,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
Ope
mportant to the continued
> success of OpenStack, although not the only ones. I would be honored to serve
> the community as a member of the TC.
>
>
> Thank you for your consideration,
> Justin Shepherd
> ___
> OpenStack-dev mai
"master" branch of Swift is now open for Icehouse
development.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
for 11 positions (6
one-year seats and 5 six-month seats), and more candidacies is always
better (thanks to Condorcet !).
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/li
Gareth wrote:
> it seems that we didn't log this channel in
> here: http://eavesdrop.openstack.org/meetings/openstack-meeting/2013/
Meetings are logged per-meeting. This one in particular is logged at
http://eavesdrop.openstack.org/meetings/project/
Cheers,
--
Thierry
Sergey Lukjanov wrote:
> I'd like to announce my candidacy for the TC.
> [...]
Confirmed.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
for taking me into consideration!
>
> -Josh
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
here: "As a TC member, I will
> place OpenStack's interests over the interests of any individual
> project if a conflict between the project and OpenStack, or a project
> with another project should a arise." - I think this is a key attitude
> we shoul
edge of the OpenStack projects
> will provide a good foundation for technical leadership.
>
> Thanks,
>
> - Chris
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
aking me into consideration.
>
> Chmouel.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Thierry Carrez (ttx)
___
and stable/grizzly so that it's ready to be
reviewed and accepted when core devs gets up.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
it's bad boto update again:
> -boto==2.13.3
> +boto==2.14.0
>
> Let's cap it as a quickfix, it's stable/grizzly freeze today so we
> need gates fixed asap!
Do we have a bug filed for this yet ? I'd like to mentio
Swartzlander, Ben wrote:
> Please consider our formal request for incubation status of the Manila
> project:
>
> https://wiki.openstack.org/wiki/Manila_Overview
Note that with the TC elections under way, this request won't be
examined until the new TC is in place.
Regards,
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
John Dickinson wrote:
> I'd like to announce my candidacy to the OpenStack Technical
> Committee.
Confirmed.
- --
Thierry Carrez (ttx)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunder
it to the release crew's attention.
Happy regression hunting,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
c/47299/
The bug was properly tagged and Russell and I should look into it soon.
I'm not a big fan of changing DB schema less than one week before final
release though.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.opens
/wiki/TC_Elections_Fall_2013
Happy voting,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
he release crew's attention.
Happy regression hunting,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ession that could be considered release-critical,
please file it at https://bugs.launchpad.net/nova/+filebug (or
https://bugs.launchpad.net/heat/+filebug if the bug is in Heat) and tag
it *havana-rc-potential* to bring it to the release crew's attention.
Happy regression hunting,
o bring it to the release crew's attention.
NB: we still have RC2 windows opened for Keystone, Ceilometer and
Horizon. Those should all be published very early next week.
Happy regression hunting,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing
ures at the beginning of a cycle
and working on bugfixes well before we enter the release candidate
phases... that's the best way to make sure your work gets in before release.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack
it to the release crew's attention.
Happy regression hunting,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
n slots allocated to another program, though
(Horizon?) to discuss UX in general and the opportunity to make it a
separate program from Horizon and TripleO.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
's
attention.
Happy regression hunting,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
m leads and
everyone else is very welcome to attend.
The meeting will be held at 21:00 UTC on the #openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131015T21
See you there,
--
net/cinder/+filebug and tag
it *havana-rc-potential* to bring it to the release crew's attention.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ad.net/keystone/+filebug and tag
it *havana-rc-potential* to bring it to the release crew's attention.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
and work within Nova
(slowly building the trust that will give you more autonomy), or ship it
as a separate add-on that does not come with nova-core's signature on it.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Alessandro Pilotti wrote:
> On Oct 16, 2013, at 13:19 , Thierry Carrez > The other two alternatives are to accept the delays and work within Nova
>> (slowly building the trust that will give you more autonomy), or ship it
>> as a separate add-on that does not come with nova-core
Daniel P. Berrange wrote:
> Alessandro, please fix your email program so that it does not send
> HTML email to the list, and correctly quotes text you are replying
> to with '> '.
+1 :)
Reference:
https://wiki.openstack.org/wiki/MailingListEtiquette
-
it to the release crew's attention.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
code at:
https://github.com/openstack/neutron/tree/milestone-proposed
If you find a regression that could be considered release-critical,
please file it at https://bugs.launchpad.net/neutron/+filebug and tag
it *havana-rc-potential* to bring it to the release crew's attention.
Cheers,
--
Thierry Carrez wrote:
> TC elections are underway and will remain open for you to cast your vote
> until at least 23:59 UTC on Thursday, October 17.
Reminder: voting closes in less than 27 hours.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailin
ential* so that it's properly documented in our release
notes as a known bug.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
about this election:
https://wiki.openstack.org/wiki/TC_Elections_Fall_2013
Congratulations to the new members, and thanks to everyone who participated.
--
Thierry Carrez (ttx)
Election official
___
OpenStack-dev mailing list
OpenStack-dev
lists:
https://wiki.openstack.org/wiki/Mailing_Lists
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e it less stressful for you all next
time.
Congrats!
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e
company at a time, if they are lucky. Other rules affect board members
of multiple companies.
Affiliation is defined by rules in the bylaws to ensure director
diversity. It's not "the company you're currently working for",
riginally). Removing or
> altering the Change-Id will prevent your patch from updating your
> existing review. The rest of your commit message can be freely rewritten.
Additionally here are a few links to our doc:
https://wiki.openstack.org/wiki/GerritWorkflow
https://wiki.ope
501 - 600 of 2055 matches
Mail list logo
