wrong. The tag is now OK, but due to some stale workspaces in our CI the
tarball was still generated from the wrong (Juno) tag.
I'll upload a new tarball ASAP. I took down the wrong one. Sorry for the
inconvenience... the issues here are not a policy problem, they are just
human e
Thierry Carrez wrote:
> I'll upload a new tarball ASAP. I took down the wrong one. Sorry for the
> inconvenience... the issues here are not a policy problem, they are just
> human error in the original tag, complicated by CI staleness that made
> us think we fixed it while we
ated by experimenters and are ready
to be stable-supported, they are moved in tree.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
changes with a
> workflow -1 to merge).
Hmm..
Ideally we'd want a blocking vote that carries over patchsets, but which
can be set or unset by any core/driver/ptl (to be determined). So if the
PTL sets the "procedural" Workflow-2 at feature freeze, I can cle
pressure to fix and make the existing projects perfect. 4 years in, we
might want to inflect that trajectory and take steps to fix this world.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Dan Smith wrote:
>> Looks reasonable to me.
>
> +1
+1
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ystem like OpenStack development.
[1] https://wiki.openstack.org/wiki/StoryBoard/Task_Lists
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
l actually get completed.
So while I agree that what you propose is the ultimate solution (and the
workflow I've pushed PTLs to follow every single OpenStack release so
far), we have struggled to have the visibility, long-term thinking and
discipline to stick to it in the past. If you look at t
f approach still sounds like an improvement to what we have
> today, which is alack of good priority communication to direct general
> review time.
+1
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
21 for Juno).
[1] https://wiki.openstack.org/wiki/SpecProposalDeadline
[2] https://wiki.openstack.org/wiki/FeatureProposalFreeze
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
in system where the core member
signs up to do stable review. He clearly says he agrees with the stable
rules and will follow them. He also signs up to do enough of them to
limit the opportunistic and accidental issues.
--
Thierry Carrez (ttx)
___
Ope
extra
mid-cycle gatherings should be focused on getting specific stuff done,
rather than general team alignment. Think workshop/hackathon rather than
private gathering. The goal of the workshop would be published in
advance, and people could opt to join that. It would be totally optional.
Cheers,
-
art is
that even after it was blessed by the TC as "the one we should all
converge on", we keep on seeing competing implementations for some (if
not all) of its scope. Convergence did not happen, and without
convergence we struggle in adoption. We need to understand why, and if
this is fix
HO really be limited to critical bugs and security issues.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
unction is keeping on top of test failures
(which is most case is just about investigating, reproducing and fixing
rare issues bugs). It's a complex task, it falls somewhere between QA
and Infra right now, and the very few resources that have the unique
combination of knowledge and will/time
themselves "OpenStack something" (which is what living
under the openstack/* namespace gives you) just because they happen to
compete with an existing openstack project sounds like a recipe for
making sure "openstack" doesn't mean anything upstream anymore.
Regards,
nk the proposed split makes a lot of sense. Let's wait for the
feedback of the affected programs to see if it's compatible with their
own plans.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://l
Zane Bitter wrote:
> On 11/08/14 05:24, Thierry Carrez wrote:
>> This all has created a world where you need to be*in* OpenStack to
>> matter, or to justify the investment. This has created a world where
>> everything and everyone wants to be in the "OpenStack"
ze and the open source
> network drivers would be difficult to mitigate through testing and could
> lead to site wide downtime
>
> 3. Rebooting VMs may be possible to schedule in batches but would
> need to be staggered to keep availability levels
What minimal level of "hot"
y
to solve potential decision deadlocks in teams (insert your favorite
dysfunctional free software project example here). We could get rid of
the PTL concept (to replace them for example with a set of designated
liaisons) and we would still have programs (teams) and projects (the
code repos that
ectgroup
and rename a project, so I'd like to get approval on it before moving to
ask them for help.
Comments, thoughts ?
[1] https://blueprints.launchpad.net/openstack
[2] https://bugs.launchpad.net/openstack
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
many deadlocks in OpenStack is
precisely *because* we have a system to break them if they arise. That
encourages everyone to find a lazy consensus. That part of the PTL job
works. Let's fix the part that doesn't work (scaling/burnout).
--
Thierry Carrez (ttx)
_
lls them (which is a possibility), it's clear and public that
there is a gap. Today the gap just ends up on the PTL's list of other
things to also do.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
Daniel P. Berrange wrote:
> On Fri, Aug 22, 2014 at 02:33:27PM +0200, Thierry Carrez wrote:
>> Hi everyone,
>>
>> We all know being a project PTL is an extremely busy job. That's because
>> in our structure the PTL is responsible for almost everything in a pro
Zane Bitter wrote:
> On 22/08/14 08:33, Thierry Carrez wrote:
>> We also
>> still need someone to have the final say in case of deadlocked issues.
>
> -1 we really don't.
I know we disagree on that :)
>> People say we don't have that many deadlocks in Op
graduate. Zaqar would also be a good candidate for
> pushing metadata changes to servers, to resolve the performance issues
> currently caused by polling.
Could you expand on that ? Do you need some kind of user-facing queue
service, or is there something in the marc^WZaqar approach th
ot;bigger more
> integrated project" vs. "smaller more focused project" difference that
> won't let us do a pattern here. We can certainly document the
> responsibilities and let programs know there are some best practices.
In smaller programs
require the TC to step in with threats of
removal of OpenStack and/or to force an election/vote in the middle of
the crisis. I'm really failing to see how that would result, in those
hypothetical crisis scenarios, in a better outcome.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
all
onto the PTL lap, but which could be delegated. If some programs want to
keep it the way it is (with the PTL being responsible for all those
duties), it's totally fine.
It's a framework for clear delegation within the current system, not a
whole new system :)
--
Thierry Carrez (ttx)
_
an't hurt, and we could turn that into a new requirements list.
Would you be interested in proposing a basic "new projects in existing
program requirements" list as a governance repo change ? Then we could
iterate on it.
Cheers,
--
Thierry Carrez (ttx)
_
Doug Hellmann wrote:
>
> On Aug 22, 2014, at 5:59 AM, Thierry Carrez wrote:
>
>> TL;DR:
>> Let's create an Oslo projectgroup in Launchpad to track work across all
>> Oslo libraries. In library projects, let's use milestones connected to
>> published
issing ?
At first glance I don't think we need a role for logistics (chairing
meetings and organizing meetups), design summit planning, roadmapping,
user point of contact, or spokesperson -- as I expect the PTL to retain
those roles anyw
tive ? How
doable would a migration to saml at this point be ? I'm trying to find a
solution so that we can ship this feature :)
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openst
at. Also if you have alternative proposals that would make a
better use of our 4 days, let me know.
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Daniel P. Berrange wrote:
> On Wed, Aug 27, 2014 at 02:51:55PM +0200, Thierry Carrez wrote:
>> [...]
>> I think this proposal makes the best use of our setup: discuss clear
>> cross-project issues, address key specific topics which need
>> face-to-face time and broa
Thierry Carrez wrote:
> Doug Hellmann wrote:
>> This makes sense to me, so let’s move ahead with your plan.
OK, this is now done:
Project group @ https://launchpad.net/oslo
Oslo incubator: https://launchpad.net/oslo-incubator
oslo.messaging: https://launchpad.net/oslo.messaging
ose tools.
And that's part of where the gate burnout comes from: spending so much
time on the issues themselves that you can no longer work on preventing
them from happening, or making the job of handling the issues easier, or
documenting/mentoring other people so that they can do it in you
an
exception for the Python client projects, so the Nova team could work on
the Nova project *and* the Python client for it. But then it made sense
to organize the code differently, so rather than continuing to add
exceptions (which you can see traces of at stale page [1]), the easiest
way to organi
re experts on.
Maybe VMWare driver people should just +2 VMware-related code. We've had
that discussion before, and I know there is a dangerous potential
quality slope there -- I just fail to see any other solution to bring
that 750/21=36 figure
Sean Dague wrote:
> On 08/28/2014 03:06 PM, Jay Pipes wrote:
>> On 08/28/2014 02:21 PM, Sean Dague wrote:
>>> On 08/28/2014 01:58 PM, Jay Pipes wrote:
>>>> On 08/27/2014 11:34 AM, Doug Hellmann wrote:
>>>>> On Aug 27, 2014, at 8:51 AM, Thierry Car
Anne Gentle wrote:
> On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez <mailto:thie...@openstack.org>> wrote:
>
> Hi everyone,
>
> I've been thinking about what changes we can bring to the Design Summit
> format to make it more productive. I've
topic.
> [1] https://wiki.openstack.org/wiki/ProjectTypes
>
> I *can* edit that page; I'd like to bring it up-to-date. It seems like a
> good basis for explaining the difference between Programs and Projects
> and the historical reasons for the split. I'
e stable/juno branch
> and starting to update the incubator as soon as the oslo.log repository is
> imported (https://review.openstack.org/116934).
>
> Thoughts?
>
> Doug
>
>
> _______
> thought the Programs got Design summit time, not projects... If not, can
> the Programs get design summit time?
Sure, that's what Anne probably meant. Time for the program behind every
incubated project.
Regards,
--
Thierry Carrez (ttx)
#x27;s entirely possible that the Kitty program
> might have a mix of Integrated and non-Integrated projects.
>
> Is it safe to assume that the Governance repo is canonical and
> up-to-date, and rework the wiki pages based on the information in the
> Governance
really means *today is the last day for feature reviews*.
So please plan that extra review effort today, rather than tomorrow !
Thanks everyone for helping us do a successful Juno release.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack
Hayes, Graham wrote:
> On Fri, 2014-08-29 at 17:56 +0200, Thierry Carrez wrote:
>> Hayes, Graham wrote:
>>> Would the programs for those projects not get design summit time? I
>>> thought the Programs got Design summit time, not projects... If not, can
>>>
ging today -
> and doing an alpha-0 tag at the opening of a new cycle just feels a
> little odd to me.
If my analysis above is right, I don't think we need to change anything:
the issue in pbr is only triggered if you try to do something you should
not do (i.e. have setup.cfg <= ta
r their release monkey) to
untarget all features that are not already gating: only features with
approved patches stuck in the gate will be kept on the list.
Thanks for helping us do a successful Juno release!
--
Thierry Carrez (ttx)
___
OpenStack-d
nteresting privacy issues that may just hinder adoption of
said solution.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
penstack.org/wiki/Meetings/TripleO
>
> but I don't know how to reflect the change in the iCal feed. Anyone
> willing to do that, please?
Time updated. For some reason I don't get notified on that page change
anymore. Sigh.
Also:
http://lists.openstack.org/piperm
nce, any news on that? Should we reboot the project?
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ation between the drivers in sync.
> [...]
At this point it may look like our current structure (programs, one PTL,
single core teams...) prevents us from implementing that solution. I
just want to say that in OpenStack, organizational structure reflects
how we work, not the other way around. If
think they yield the same
end result, but the -1 approach seems to be a bit more unfair, since it
would be purely for reasons we don't (yet) apply to currently-integrated
projects...
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
a bit more publicity, larger pods and where we use
all the summit space available for pods :)
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ject will be using its pod
> space when its design session track is in-progress, so the pod could
> be passed on to another project)
We'll have to design some novel pod-switching algorithm, but I kinda
want to know how many pods we can have before
scheduling.
We have until the week after release to finalize the summit schedule, so
plenty of time. Also there will be Kilo PTLs elections in the middle of
this (end of September), and the Kilo themes are actually a Kilo PTL thing.
--
Thierry Carrez (ttx)
___
Tim Bell wrote:
>> -Original Message-
>> From: Thierry Carrez [mailto:thie...@openstack.org]
>> Sent: 04 September 2014 16:59
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose during
>> t
impossible task of keeping the Nova ship straight in troubled waters
while we head toward the Juno release port.
Regards,
[1] https://wiki.openstack.org/wiki/FeatureFreeze
[2] https://wiki.openstack.org/wiki/StringFreeze
[3] https://wiki.openstack.org/wiki/DepFreeze
--
Thierry Carrez (ttx
ig pull requests to integrate subsystem trees.
Please note that the Kernel subsystem model is actually a trust tree
based on 20 years of trust building. OpenStack is only 4 years old, so
it's difficult to apply the same model as-is.
--
Thierry Carrez (ttx)
__
Nova, that means that more than 7 exceptions is
starting to be a stability issue.
Please keep that in mind every time you go to support a FFE.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think it makes a lot of sense but it also has a lot of documentation
consequences. If it was ready to merge and had the necessary reviews
piled up I would +1 this but the way it stands now (and given Glance's
current review velocity) I'm more leaning towards -1.
Chee
ed to merge
quickly, and the current Glance review velocity is not exactly feeding
my hopes. +0 as far as I'm concerned, and definitely -1 if it takes more
than one week.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenS
gt;>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-
va-approved-ffes
It would also be great if the contents of that list matched the
Launchpad milestone page we use to track progress on them:
https://launchpad.net/nova/+milestone/juno-rc1
Cheers,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailin
f it is thrown. That is better than breaking the coding
>> standard imho.
>>
>> Jay
>>
>> On Sep 5, 2014 3:30 PM, "Matt Riedemann" > <mailto:mrie...@linux.vnet.ibm.com>> wrote:
>>
>>
>>
>> On 9/5/2014 5:10 AM, Thierry Carr
#x27;t implicitly expire and
> will cause unexpected behaviours (see [1]) like gate failures. In our
> case this caused non-deterministic failures on the dsvm-functional test
> suite.
Nice catch, John!
--
Thierry Carrez (ttx)
___
OpenStack-dev
John Griffith wrote:
> Yes, now that RC1 is tagged I'm planning to tag a new cinderclient
> tomorrow. I'll be sure to send an announcement out as soon as it's up.
You mean, now that juno-3 is tagged ;) RC1 is still a few weeks and a
few dozens bugfixes away.
--
a bit of
cross-project coordination to get it in in time... I expect the same to
happen again.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nd allows seamless upgrades. This is
another way of looking at "paying our technical debt" that others have
mentioned as goals -- generally polishing what we have rather than
building out new things.
Regards,
--
Thierry Carrez (ttx)
_
he
message-broker case, I'm also not convinced building it on top of
postfix/dovecot would be a net win compared to building it on top of
Redis, to be honest.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
one know
> if it's going to come back? Or should we just purge those links?
It used to be a convenient way to graph bug stats from launchpad over
time. But I think the service died. So yes, links can probably be purged
now.
--
Thierry Carrez (ttx)
___
ction of the tests being run at the gate, which should address
most of the harm you see in adding additional repositories. But I agree
there is little point in discussing splitting virt drivers (or anything
else, really) until the internal interface below that potenti
state function for backups absolutely needs to be in Juno ? Feels
like a nice-to-have to me, and I fear we are past that point now.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/
that something only doing A would be simpler, while
covering most of the use cases?
Is it something else ?
I want to make sure I understand your objection. In the "user
perspective" it might make sense to pursue both options as separate
projects. In the "deployer perspective" cas
V1 in Kilo, and then have to deprecate it for n cycles just because
it was shipped in the official release and therefore inherits its API
deprecation rules.
Regards,
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Duncan Thomas wrote:
> On 12 September 2014 09:54, Thierry Carrez wrote:
>> At this point, unless it's critical to the success of the release (like,
>> it completes a feature that is 99% there, or it increases consistency by
>> plugging a feature gap, or it
already-announced etherpads on a single page at:
https://wiki.openstack.org/wiki/Summit/Planning
Please add any that I missed !
If you think this is wrong and think the "design summit suggestion"
website is a better way to do it, let me know why! If some programs
e following patch:
>
> https://review.openstack.org/#/c/108609
I would say it's way too late at this point for a new driver in Juno. At
this point we should be focused on fixing what we already have, not add
more surface.
Cheers,
--
Thierry Carrez (ttx)
g candidate
> sessions for merging etc.
Good point. I've replaced the wording in the wiki page -- just use
whatever suits you best, as long as it's a public document and you can
link to it.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Russell Bryant wrote:
> On 09/12/2014 07:37 AM, Thierry Carrez wrote:
>> If you think this is wrong and think the "design summit suggestion"
>> website is a better way to do it, let me know why! If some programs
>> really can't stand the 'etherpad/IRC&#
in my mind as a topic that is OpenStack wide, but
> the programs it affects are quite affected, so I do feel it is time to
> mention it.
I think those discussions could happen in a cross-project workshop.
We'll run 2 or 3 of those in parallel all day Tuesday
Mike Perez wrote:
> On 14:24 Fri 05 Sep , Alex Meade wrote:
>> Hi Cinder Folks,
>>
>> I would like to request a FFE for cinder pools support with the NetApp
>> drivers[1][2].
>
> Looks like this is being reviewed now.
Looks like it merged, so I retroactiv
that just seems like a natural separation line to use if
we do split. But that would just be a first step: as more internal
interfaces are cleaned up we could (and should) split more. Smaller
groups responsible for smaller areas of code is the way to go.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
moved too.
> [...]
IMHO code refactoring should be considered a superfluous change at this
point in the cycle. The risk/benefit ratio is too high, and focus should
be on bugfixing at this point.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
O
nd the remaining 25% on some
random channel the right people happen to be in. Having a clear channel
where all the gate liaisons hang out and all issues are discussed may go
a long way into establishing a team to work on that (rather than
continue to rely on th
an participate.
>>
>> Last summit the Operators Track ran on the Monday and the Friday giving
>> folks who usually spend most of the time at the Design summit to
>> participate and hear the operator's voices. I know I did and I found it
>> highly educational.
&
g the
distributions, so let's wait for the packagers to chime in on how much
of a disruption that would cause to them at this point.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the same version though, I just
> need to add a new tag, which isn't much of a problem for me (since I use
> a git based workflow).
>
> The 1.4.0.0a5 is confusing... :(
According to Donald Stufft PEP 440 now allows 1.4.0.a5 now so we may not
need that extra 0
deeply rooted in the code and architecture
that Zaqar won't naturally mutate to support that use case.
The Zaqar team has shown great willingness to adapt in order to support
more use cases, but I guess there may be architectural design choices
tha
And it's really
difficult to get good locations and times (and prices) if you don't book
at least 2 years in advance.
## The Foundation bylaws
There are a number of terms used in the bylaws, and we may need to map
our new structure to it, make sure it doesn't require a bylaws change
ight
need some extra communication to work seamlessly.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
pen source + free as in beer solution based on WebRTC:
https://meet.jit.si/
No account needed, no participant limit.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
therpad.openstack.org/p/common-openstack-ml-topics
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Thierry Carrez wrote:
> Thierry Carrez wrote:
>> The two candidates who nominated themselves in time for this election are:
>>
>> * David Lyle
>> * Matthias Runge
>>
>> The election will be set up tomorrow, and will stay open for voting for
>> a wee
Once they are set to "Low" priority they mostly disappear
from release management tracking so it's not really a burden there.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
esults would be extremely
user-specific (and leaking data from one user to another would be
catastrophic), so the benefits of indexing (vs. querying DB) would be
very limited ?
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.ope
something I'd ignore (by setting up
yet another filter), it would be something I would actually enjoy reading.
--
Thierry Carrez (ttx)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
to say).
Ideally we would have a single forum for all of those, rather than have
to fish for each appropriate wiki page. If everyone posted to planet.o.o
that would be a start... Some other aggregator or site (like the one
Flavio suggested) cou
Only 10 days left -- and there aren't that many OpenStack talks
submitted yet.
If you plan to be around and you have a topic to discuss that may be
interesting for a developers audience, please consider submitting a talk !
Thierry Carrez wrote:
> There will be a two-day "Virtualisa
1 - 100 of 2055 matches
Mail list logo
