I'll put them in that pool.
>>
>
> I'm hoping the ArchWG lands on that list. We'll probably need some face
> time just to hug it out by the time summit rolls around. :)
I feel like the Arch WG could steal one of the cross-project workshop
spaces, if you propose it
pet
>
> As you can see, we don't have much topics now, so I'm quite sure we
> could give one wr to you.
I keep a list of non-official-yet-but-could-use-summit-space teams, and
will propose any leftover space to them soon. Let me kn
Thierry Carrez wrote:
> Doug Hellmann wrote:
>> Excerpts from Jay Pipes's message of 2016-09-09 14:30:29 -0400:
>>> > To me, this statement
>>>> about One OpenStack is about emphasizing those commonalities and
>>>> working together to increase t
use all of your
allocated slots, let us know so that we can propose them to other teams.
Time to start thinking about the content you'd like to cover during
those sessions and warm up those Ocata etherpads !
Cheers,
--
ast it should happen in a logged channel.
I think reusing #openstack-dev for this is fine -- it's an activity that
is limited in time (so doesn't need a permanent channel) and -dev is
pretty inactive those days.
--
Thierry
s on our
mission more than on governance details. It is important for open source
projects to have a strong governance model, but it is only the frame
that holds the canvas and defines the space. The important part is the
paint
that we never achieved, and which is,
in my opinion, not desirable at this stage. I think that saying "a
framework" would be more accurate today. Something like "OpenStack is
one community with one common mission, producing one framework of
collaborating components" would c
eed someone there
to collect their feedback and start thinking about the next cycle,
otherwise you're just pretending to listen. That's why I think it's a
good idea to have someone more obviously focused on the next cycle
designated by then, to coordinate that feedback. But then
Thierry Carrez wrote:
> [...]
> One interesting side-effect is that since the timing of the election
> period (for PTL and TC positions) is defined in the TC charter[3]
> relative to the *Summit*, it means that (unless we change this) we'll
> now run elections to renew PTL and
rm". If you take into account that the work on a release
cycle starts well before the development branches are open, then it's
the current elections that happen "midterm". Whenever you choose, it's
always at the start of something and the middle of something else.
--
Thie
lopment cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development b
yourselves, you should be able to reach out to the infra team so that
they fix the group for you.
Thanks in advance,
[1] https://review.openstack.org/#/admin/groups/
[2]
http://docs.openstack.org/project-team-guide/release-management
history
properly which caused the issue. Took us some time to gather the courage
to write it, then finally Monty wrote a draft, and I turned it into a
change.
[1]
http://eavesdrop.openstack.org/meetings/openstack-meeting/
y of the PTL
happens at election time in my case (as defined in the TC charter),
while you suggest it happens 3 months later, when development on N+1 starts.
One thing to note is that unless someone proposes a TC charter change
during Ocata, the authority of the newly-elected PTL starts at election
time,
s you use someone else if you want to. A bit
like keeping a headphone jack. Options.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
's meant to
document *existing* principles that we operate under but never
documented properly. It's not really about a new set of rules, or really
changing anything.
Please share your thoughts on the review or this thread !
--
Thierry Carrez (ttx)
Sean Dague wrote:
> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
>> Barrett, Carol L wrote:
>>> From: Sean Dague [mailto:s...@dague.net]
>>>> I think another option would be to run the PTL election early, but just
>>>> don't have the turn ove
ng project. The list of acceptable licenses
includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL. Licenses
considered incompatible with this requirement include GPLv2, GPLv3, and
AGPL."
[1] http://governance.openstack.org/reference/
ck of this approach is that it breaks the governance model
around project teams. You need a "the buck stops here" person (even if
that power is seldom used). But you can't have two -- what happens if
they disagree ?
So it's simpler to ha
Davanum Srinivas wrote:
> Doug, Thierry,
>
> Do we want the stewards to serve as the CPL for Release team as well?
Yes, they probably would be an evolution of the current release
liaisons. Like I said in the email, "a sort of per-cycle release liaison
on steroids".
--
org/ptg
[2] http://www.openstack.org/ptg/ptgfaq/
[3]
http://governance.openstack.org/reference/charter.html#election-for-ptl-seats
[4]
http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png
--
Thierry Carrez (ttx)
Davanum Srinivas wrote:
> +1 Welcome Tony!
+1
Hopefully we won't break him by stretching him even more :)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opens
Ian Wienand wrote:
> diskimage-builder would like to request a feature/v2 branch.
> [...]
Sure thing.
What would you like the branching SHA to be ? Current HEAD ?
We can continue this discussion on #openstack-release.
--
Thierry Carre
ruary. The proposed Ocata
release schedule reflects that: https://review.openstack.org/#/c/357214/
Regards,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-re
s Nova for me in the
> next (hopefully short) time. That means I'm resigning from the bug czar
> role as of now.
> [...]
Thanks Markus for your service there!
--
Thierry Carrez (ttx)
__
OpenStack Development Mai
rstand and maintain operationally. It should only be done as a last
resort, with pros and cons carefully weighted. We really should involve
operators in this discussion to get the full picture of arguments for
and against.
--
Thierry Carre
emed to have missed the thread where upstream opps we're being
> announced and/or opened. Who do I contact to get in on this? I had
> table duty last year and couldn't do it.
What do you mean by "upstream opps" ?
--
Thierry Carrez (ttx)
__
Clint Byrum wrote:
> [...]
> I think it's about time we get some Architecture WG meetings started,
> and put "Document RPC design" on the agenda.
+1
Anything blocking you ? Let me know where/if I can help.
-cases and what are the missing elements.
Agreed that a bottom-up, incremental improvement strategy sounds more
likely to succeed in an established project like OpenStack (compared to
a big-bang top-bottom re-architecture).
--
Thierry Carrez (ttx)
__
means next time I wonder what (for example) vIMS could
mean, I'll ask you. (would be great if it was an attempt at virtualizing
and cloning dims)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage
en validation of the plan and assessment of how that could be rolled
out OpenStack-wide would involve the Arch WG (and ultimately probably
the TC).
The former approach is a lot easier than the latter :)
--
Thierry Carrez (ttx)
__
ds up being distributed in their
customers homes (and conveniently using your own electricity/cooling) ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
goals are smallish development cycle
goals. They are specifically chosen to be complete-able within a cycle
and with a clear definition of "done". It's what differentiates them
from more traditional cross-project specs or strategic initiatives which
can be more long-term (and on
with it.
+2ed (the solution, the rationale and the patch)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http:/
would be great as well, to further give operators
> data on what vendors are working in good faith and which aren't.
I like this a lot, and it certainly would address the deprecation policy
part.
Sean: I was wondering if that would not still be considered breaking
upgrades, though... Sin
aningless waste of time and
> energy.
I think we can find wording that doesn't use the word "priority" (which
is, I think, what John objects to the most) while still conveying that
project teams are ex
ou don't like it you should drop OpenStack altogether, I suspect you'd
get a pretty sad response.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ.
me.
In that other thread I proposed two tiers (in openstack/cinder following
deprecation and stable policies and in a separate Cinder repository if
you don't trust it to follow the policies) since the Cinder team sees
value in keeping them cinder-core-reviewed and in a limited number of
reposi
Or is there another benefit in shipping everything inside a single
repository that you didn't mention ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-re
at doesn't mean you would prioritize that (as in "do
it first") over urgent things like fixing a bug that results in data
corruption or a significant vulnerability. It means it should be a
priority to get that done over the cycle. It should be seen as a "must
have" rat
de) gain, but I think it would provide the most
useful information to our users and therefore the best operational
experience...
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
Thomas Goirand wrote:
> On 08/01/2016 09:39 AM, Thierry Carrez wrote:
>> But if a project is persistently single-vendor after some time and
>> nobody seems interested to join it, the technical value of that project
>> being "in" OpenStack rather than a se
her hand, projects that are clearly part of the marketing
strategy of one particular vendor, and the project is not generally as
useful to the rest of the community, and I'd advocate that those should
not stay under TC governance as an official OpenStack project.
--
Thierry Carrez (ttx)
who elected me in, thank you.
Sorry to see you go, Morgan. Stepping down gracefully when our
priorities no longer align with the positions we hold is one of the
principles OpenStack is based on, and you demonstrated it well. Thanks
for your input and vision!
--
T
ing like an OpenStack project and then a case could be opened for
removal, but there is nothing new here.
--
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
we'll be able to free up more time to discuss such horizontal
issues, but as far as Barcelona goes (where we have less space and less
time than in Austin), I'd encourage you to still propose cross-project
workshops (and engage on the Ops side of the Design Summit t
without
structurally resisting contributions. But being able to trigger a review
after some time, to assess if we have reasons to think it will improve
in the future (or not), sounds like a good idea.
--
Thierry Carrez (ttx)
_
part of the naming. We probably
wouldn't have that discussion either if the Fuel team affiliation was
more diverse and the new repositories were an experiment of a specific
subgroup of that team.
NB: I *do* have some concerns about single-vendor OpenStack projects
that don't grow more div
as long as nobody else used
rootwrap (or all those hypothetical users would migrate to privsep).
In summary: I can live with the patch as proposed, as long as Angus is
fine with it.
--
Thierry Carrez (ttx)
__
OpenStac
I
think will improve things in the right direction, let's see how those
pan out. Please be patient while we are rolling those out.
So in summary: yes there still are issues, but it is not a simple
problem, and we are working on it.
--
Thierry Carrez (ttx)
_
Julien Danjou wrote:
On Sat, Jul 16 2016, Thierry Carrez wrote:
Julien Danjou wrote:
Something is very unclear (but I'm getting used to it lol): are theses
logo created for projects or teams?
We have 4 different projects (Aodh, Gnocchi, Ceilometer & Panko) in the
Telemetry team.
Sean Dague wrote:
On 07/04/2016 05:36 AM, Sean McGinnis wrote:
On Mon, Jul 04, 2016 at 01:59:09PM +0200, Thierry Carrez wrote:
[...]
The issue here is that oslo.rootwrap uses config files to determine
what to allow, but those are not really configuration files as far
as the application using
r. For example, we talked recently about having the Technical
Committee set "release goals" to drive simple coherence and visible
improvements across all the components of the stack.
--
Thierry Carrez (ttx)
__
OpenStac
ould not
really "compete" against each other (but rather all projects should
contribute to the success of OpenStack as a whole) and (2) some
OpenStack projects will always be more equal than others (for example we
require that every project integrates with Keystone, and I don't
m, but my understanding is that it's a mascot
per team, not per deliverable within that team. So in your case that
would be the "Telemetry" mascot.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List
g an unofficial project if it's usable,
doesn't have critical security issues and is used by a number of
people... Now, if it's unusable and abandoned, that's another story.
--
Thierry Carrez (ttx)
__
Open
at we want eventually, but
it's not how we advertise it today.
Well, some (most ?) distros ship them as code rather than configuration,
under /usr/share rather than under /etc. So one may argue that the issue
is that devstack is installing them under /etc :)
--
Thie
both old and new
commands to run until the Mitaka files are cleaned up). That might be an
option if we don't want to special-case rootwrap files (the way they
should always have been special-cased) in Grenade. Making rootwrap find
that new location without requiring altering its configur
like. If we can
get more quality/curated content there we might start a virtuous circle
-- getting developers more present there can only help.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for
so we'll likely retire it ASAP.
I'll let Doug do the long answer when he finishes processing his ML backlog.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
at's fine, but only if we get rid of
rootwrap soon. So only if we have a plan for (4) anyway. Option (0) is a
bit of a hard sell for upgrade procedures -- if we need to take a hit in
that area, let's do (4) directly...
In summary, I think the choice is between (1)+(4) and doing (4)
di
why architecture should be the reserved domain of
precisely 13 people. We are electing the TC to make final calls where
needed. Not to be the only people that are allowed to work on
architecture. For that, an open workgroup sounds a thousand times be
fails), the TC can make a top-down request to a project to do things a
certain way. The project can them either comply or reject the TC
oversight and become an unofficial project.
--
Thierry Carrez (ttx)
__
Open
Davanum Srinivas wrote:
Matthew Thode (prometheanfire)
Dirk Mueller (dirk)
Swapnil Kulkarni (coolsvap)
Tony Breeds (tonyb)
Thomas Bechtold (tbechtold)
+1
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not
that requires human judgment here. In your example
above, if the open implementation was unusable open core bait to lure
people into using the one and only proprietary driver, it would be a
problem. If the open implementation was fully functional and nothing
prevented
official OpenStack
project team -- all those we bless need to be reasonably-level playing
fields.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists
329448/.
* The project provides a level playing field for interested developers to
collaborate. Where proprietary software, hardware, or other resources
(including testing) are required, these should be reasonably accessible to
interested contributors.
I replied to that on the review :)
--
Thie
the end goal: we just have to choose between "pass fail
pass" and "pass pass* pass" as a way to achieve it. I feel like the
latter is a shorter path to the desired goal, and reduces the
possibility of a "pass fail f*k-this-shit" rage outcome.
--
Thierry Carrez (ttx)
l" list in the governance repo.
Right, as Doug says, I don't expect Designate to have to change anything
if this passes. As long as you accept considering new drivers, I would
consider that a level playing field (same as the Cinder case I mentioned
in my
pository,
be plugged into the gate... but as an unofficial project.
So I think we can keep the benefits of having those drivers being open
source (including visibility and long-term maintenance), while
guaranteeing official "OpenStack" projects present a
ect should probably live as an
unofficial OpenStack project.
Comments, thoughts ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?su
ike this when looking at master:
...
1.5.0
1.5.1
1.5.2rc1
1.6.0
...
We don't do this hybrid anymore for intermediary-released projects,
everything is tagged directly. So you might still be missing stable
release tags when running git tags on master, but while that may still
be slightly confus
more practice
sharing and reduce fragmentation in "OpenStack" in general. We might
just need to put the bar pretty high so that we are not flooded by silly
rewrite requests.
For completeness I'll also list the nuclear option: to reject the
solutions for (2), and research potential tools for (3) and (4).
Thanks again for the feedback!
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.op
Hi there,
Due to obvious inactivity I proposed the removal of the Cue project team
from the "Big Tent" list of official OpenStack projects under Technical
Committee governance:
https://review.openstack.org/324412
Please comment on that review if you think it's the wrong ca
Yanyan Hu wrote:
Aha, it's pretty interesting, I vote for Zun as well :)
I don't get to vote, but since I was the one to suggest Higgins in the
first place, I must admit that Zun sounds like a good alternative.
--
Thierry C
x27;s continue discussing on the review, and sorry for the noise :)
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
ed to have a longer conversation that is likely
to extend beyond the release model deadline tomorrow.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
warding very quickly. And the tools generally handle the distinction
between bug reporting and task tracking poorly... Which leads to the
dilemma of throwing out unqualified symptoms data to keep the tool
usable to orga
then, no date is perfect.
--
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/ma
for Designate's MiniDNS (and other partial
optimizations), but I'm not sure that would work in the Hummingbird
case, where all the node is rewritten in Go. If we mandated that
approach, that would probably mean a lot of rework there...
I'd prefer if we didn't have to special-case anyone, and we could come
up with general rules that every OpenStack project follows. Any other
solution is an administrative nightmare and a source of tension between
projects (why
2011 which was never
overruled or changed afterwards:
"OpenStack is a single product made of a lot of independent, but
cooperating, components."
The log is an interesting read:
http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-06-28-20.06.log.html
ge is appropriate might be the
solution...
That is what I mean by 'scope': where does "OpenStack" stop, and where
do "OpenStack dependencies" start ? It is a lot easier and a lot less
community-costly to allow additional languages in OpenStack dependen
and
specialized areas as we got into the business of developing time-series
databases or SDNs. As a result, it's not "one community" anymore. Should
we further encourage that, or should we focus on what the core of our
mission is, what we have in common, this integration engine
onfusion/isolation/fragmentation in global/virtual communities.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
that would probably be good to talk about, but
that can probably be processed off-meeting.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
take the time to calmly measure the cost, see what
resources we have lined up to address that cost, and make a decision
from there.
[1] https://en.wikipedia.org/wiki/Externality
--
Thierry Carrez (ttx)
__
OpenStack Deve
n the Oslo branding
might hinder its out-of-OpenStack adoption. But it doesn't feel like
that is the case here ?
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
t.
So, if you use the wiki as part of your OpenStack work, make sure to
check if your use case is mentioned on the etherpad at:
https://etherpad.openstack.org/p/wiki-use-cases
If not, please add your use case, together with the URL of such a wiki
page to that etherpad.
Thanks in advance,
--
Thierry Carrez wrote:
[...]
I'll soon start a thread on that. Since that goes a lot beyond the dev
community, I'll post it to the openstack general list and post a pointer
to it here.
See
http://lists.openstack.org/pipermail/openstack/2016-May/016154.html
--
Thierry C
r solution that would just not move the
effort around.
That said I know that the Swift team spent a lot of time in the past 6
years optimizing their Python code, so I'm not sure we can generalize
this "everything to do with the algorithms" analysis to t
the dev
community, I'll post it to the openstack general list and post a pointer
to it here.
Cheers,
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: o
op the current wiki and replace it by another lightweight
publication solution (if there is anything convenient)
* Deprecate the current wiki and start over with another wiki (with
stronger ACL support ?)
--
Thierry Carrez (ttx)
r
which license applies to what.
Looks like a question/discussion for the legal-discuss ML.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
he Swift engine). To
make it really happen would probably require a separate team driving it
and/or a more... radical change on the governance side. The fact that
there is no such team forming (or more support for radical change)
suggests that the situation is not critically broken...
--
https://twitter.com/OpenStack/status/724628774961074176
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
penStack which happens to
be written in a specific language. Especially if the then-supported set
of languages could provide the same technical benefits.
--
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for
--
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
openstack-dev/2016-April/092298.html
[2] http://releases.openstack.org/newton/schedule.html
Feel free to propose an update to the Newton schedule to add those
Keystone-specific dates in ! The file to change is at:
http://git.openstack.org/cgit/openstack/releases/tree/doc/source/newton/schedule.
601 - 700 of 2055 matches
Mail list logo
