subject:"Re\\\: \\\[openstack\\\-dev\\\] TC Candidacy"

This was a riveting soapbox missive - and I agree with what you said -
particularly about the focus on breaking down the barriers to building out
and supporting the OpenStack contributor base.

But I don't have a good sense for how you want to apply that focus in
action on the TC?  I went back and looked at a number of mailing list
threads you participated in - and happily recalled your very matter of fact
presentation.  Frankly it was quite refreshing to see how often you seemed
to offer historical context more that your personal opinion (!!!)

Is there any *specific* goals you have for a one year term on the TC - or
do you think more focus on contributors is the most important thing to fix
first?  Would you perhaps consider to share your thoughts in response to
Gordon's question [1]?

-Clay

1.
http://lists.openstack.org/pipermail/openstack-dev/2016-October/104953.html


On Thu, Sep 29, 2016 at 4:47 PM, Jeremy Stanley  wrote:

> I guess I'll send a copy of mine to the ML too, since all the cool
> kids seem to be doing it...
>
> Most of you probably know me as "that short dude in the Hawaiian
> shirt and long hair." I'll answer to "Jeremy," "fungi" or even just
> "hey you." I'm starting my third cycle as PTL of the Infrastructure
> team, and have been a core reviewer and root sysadmin for
> OpenStack's community-maintained project infrastructure for the past
> four years. I've also been doing vulnerability management in
> OpenStack for almost as long, chaired conference tracks, and given
> talks to other communities on a variety of OpenStack-related topics.
> I help with elections, attend and participate in TC meetings and
> review proposed changes to governance. I have consistent, strong
> views in favor of free software and open/transparent community
> process.
>
> https://wiki.openstack.org/user:fungi
>
> I see OpenStack not as software, but as a community of people who
> come together to build something for the common good. We've been
> fortunate enough to experience a bubble of corporate interest which
> has provided amazing initial momentum in the form of able software
> developers and generous funding, but that can't last forever. As
> time goes on, we will need to rely increasingly on effort from
> people who contribute to OpenStack because it interests them, rather
> than because some company is paying them to do so. The way I see it,
> we should be preparing now for the future of our project:
> independent, volunteer contributors drawn from the global free
> software community. However, we're not succeeding in attracting them
> the way some other projects do, which brings me to a major
> concern...
>
> OpenStack has a public relations problem we need to solve, and soon.
> I know I'm not the only one who struggles to convince contributors
> in other communities that we're really like them, writing free
> software under transparent processes open to any who wish to help.
> This skepticism comes from many sources, some overt (like our
> massive trade conferences and marketing budget) while others
> seemingly inconsequential (such as our constant influx of new
> community members who are unfamiliar with free software concepts and
> lack traditional netiquette). Overcoming this not-really-free
> perception is something we absolutely must do to be able to attract
> the unaffiliated volunteers who will continue to maintain OpenStack
> through the eventual loss of our current benefactors and well into
> stabilization.
>
> Prior to OpenStack, I worked for longer than I care to remember as
> an "operator" at Internet service, hosting and telecommunications
> providers doing Unix systems administration, network engineering,
> virtualization and information security. When I first started my
> career, you couldn't be a capable systems administrator without a
> firm grasp of programming fundamentals and couldn't be a good
> programmer without understanding the basics of systems
> administration. I'm relieved that, after many years of companies
> trying to tell us otherwise, our industry as a whole is finally
> coming back around to the same realization. Similarly, I don't
> believe we as a community benefit by socializing a separation of
> "operators" from "developers" and feel the role distinction many
> attempt to strike between the two is at best vague, while at its
> worst completely alienating a potential source of current and future
> contributions.
>
> What causes software to succeed in the long run is not hype,
> limitless funding or even technical superiority, it's the size and
> connectedness of its community of volunteers and users who invest
> themselves and their personal time. The work we're doing now is
> great, don't get me wrong, but for it to survive into the next
> decade and beyond we need to focus more on building a close-knit
> community of interested contributors even if it's not in the best
> interests of industry pundits or vendor product roadmaps.
>
>

Re: [openstack-dev] TC candidacy

On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi  wrote:

>
> - Make sure it works outside Devstack.
>
> There is a huge gap between what is tested by Devstack gate and what
> operators
> deploy on the field.  This gap tends to stretch the feedback loop between
> developers and operators.  As a community, we might want to reduce this gap
> and make OpenStack testing more effective and more realistic.
> That's an area of focus I would like to work and spread over OpenStack
> projects if I'm elected.
>
>
This is a really interesting platform point.  It's been a concern in he
community since *at least* Vancouver [1].  We've had lots of different
viewpoints towards project install-ability raised this election:

   - John Dickenson says installation of projects should go horizontal [2]
   - Monty Taylor says services oriented deployment teams are the wasteful
   exception [3]
   - John Griffith says how the TC approaches services oriented OpenStack
   will be an important factor in the future definition of OpenStack and it's
   relevancy [4]

Do you think this is an important topic for OpenStack right now?  I'd be
really interested to hear any *new* insights from the previous PTL of *one*
of OpenStack's installation automation projects?  What could or should be
done to reduce the bias/reliance towards a devstack or an
"openstack-all-in-one" deployment model?  Can or should the TC be the
champion of the discussion around "how to install" OpenStack?  How much of
an impact does choices made in *testing* effect the install-ability and
ease-of-use of OpenStack in general?

Somewhat unrelated.  Do you have any personal thoughts/insights on how you
believe OpenStack should approach potentially disruptive or "competing"
design in general - like ansible/puppet or even Kolla?

-Clay

1. https://www.youtube.com/watch?v=ZY8hnMnUDjU=youtu.be=379
2.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104815.html
3.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104844.html
4.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104833.html
__
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

Re: [openstack-dev] TC candidacy

I just re-read your announcement - and I couldn't be happier you're running
:D

I was so surprised at the fallout from your suggestion that the TC should
actively engage in more broadcasting of important topics [1] to bring in
more voices from the community early!?  Links to IRC logs and Gerrit commit
history seemed to totally miss the point?

I'm curious if any other discussions or questions on the mailing list have
excited or frustrated you in the past week?  Is there any specific goals
you have for a one year term on the TC - or do you think more clarity on
past "perceived agreements" and a better focus on visibility and
communication is the more important thing to fix first?

Thanks again,

-Clay

1. This is a great example how much this attitude of "full contact
community engagement" is *needed* and how much it's *lacking* with the
current set of representatives ->
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103223.html -
not surprisingly it took someone from "the outside" to make it happen!

On Wed, Sep 28, 2016 at 9:41 AM, Chris Dent  wrote:

>
> Despite its name, the Technical Committee has become the part of the
> OpenStack contributor community that enshrines, defines, and -- in some
> rare cases -- enforces what it means to be "OpenStack". Meanwhile,
> the community has seen a great deal of growth and change.
>
> Some of these changes have led to progress and clarity, others have left
> people confused about how they can best make a contribution and what
> constraints their contributions must meet (for example, do we all know
> what it means to be an "official" project?).
>
> Much of the confusion, I think, can be traced to two things:
>
> * Information is not always clear nor clearly available, despite
>   valiant efforts to maintain a transparent environment for the
>   discussion of policy and process. There is more that can be done
>   to improve engagement and communication. Maybe the TC needs
>   release notes?
>
> * Agreements are made without the full meaning and implications of those
>   agreements being collectively shared. Most involved think they agree,
>   but there is limited shared understanding, so there is limited
>   effective collaboration. We see this, for example, in the ongoing
>   discussions on "What is OpenStack?". Agreement is claimed without
>   actually existing.
>
> We can fix this, but we need a TC that has a diversity of ideas and
> experiences. Other candidates will have dramatically different opinions
> from me. This is good because we must rigorously and vigorously question
> the status quo and our assumptions. Not to tear things down, but to
> ensure our ideas are based on present day truths and clear visions of
> the future. And we must do this, always, where it can be seen and
> joined and later discovered; gerrit and IRC are not enough.
>
> To have legitimate representation on the Technical Committee we must
> have voices that bring new ideas, are well informed about history, that
> protect the needs of existing users and developers, encourage new users
> and developers, that want to know how, that want to know why. No single
> person can speak with all these voices.
>
> Several people have encouraged me to run for the TC, wanting my
> willingness to ask questions, to challenge the status quo and to drive
> discourse. What I want is to use my voice to bring about frequent and
> positive reevaluation.
>
> We have a lot of challenges ahead. We want to remain a pleasant,
> progressive and relevant place to participate. That will require
> discovering ways to build bridges with other communities and within our
> own. We need to make greater use of technologies which were not invented
> here and be more willing to think about the future users, developers and
> use cases we don't yet have (as there will always be more of those). We
> need to keep looking and pushing forward.
>
> To that end I'm nominating myself to be a member of the Technical
> Committee.
>
> If you have specific questions about my goals, my background or anything
> else, please feel free to ask. I'm on IRC as cdent or send some email.
> Thank you for your consideration.
>
> --
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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 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

Re: [openstack-dev] TC Candidacy

On Thu, Sep 29, 2016 at 8:34 PM, John Griffith 
wrote:

>
>
> I think what's more important and critical is the future and where
> OpenStack is going over the course of the next few years.
>

I think this is a really important topic right now!  Do you see any
dangerous road blocks coming up!?


>
> Do we want our most popular topic at the key-notes to continue being
> customers telling their story of "how hard" it was to do OpenStack?
>

No ;)


>
> It's my belief that the TC has a great opportunity (with the right people)
> to take input from the "outside world" and drive a meaningful and
> innovative future for OpenStack.  Maybe try and dampen the echo-chamber a
> bit, see if we can identify some real problems that we can help real
> customers solve.
>

I think this is where we *all* should be focused - do you think the TC can
offer specific support to the projects here - or is more about just
removing other roadblocks and keeping the community on target?


> I'd like to see us embracing new technologies and ways of doing things.
> I'd love to have a process where we don't care so much about the check
> boxes of what oslo libs you do or don't use in a project, or how well you
> follow the hacking rules; but instead does your project actually work?  Can
> it actually be deployed by somebody outside of the OpenStack community or
> with minimal OpenStack experience?
>
> It's my belief that Projects should offer real value as stand-alone
> services just as well as they do working with other OpenStack services.
>

Very controversial (surprisingly?)!  Why do you think this is important?
Do you think this is in conflict with the goal of OpenStack as one
community?



>
> Feel free to ask me about my thoughts on anything specific, I'm happy to
> answer any questions that I can as honestly as I can.
>

Don't mind if I do ;)

-Clay
__
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

Re: [openstack-dev] TC candidacy

2016-09-30 Thread Brad Topol


I have known Mr. Taylor for many years and I would like to come out as his
first endorser for his big league thoughts and recommendations below.


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Monty Taylor <mord...@inaugust.com>
To: openstack-dev@lists.openstack.org
Date:   09/29/2016 07:29 PM
Subject:        Re: [openstack-dev] TC candidacy



On 09/29/2016 06:14 PM, Clint Byrum wrote:
> https://review.openstack.org/379850
>
> Let's make OpenStack great again.
>
> If you don't know me, I'm very good. The code and designs I make
> are tremendous, and I intend to contribute to the TC bigly. The other
> candidates are sad, and they want OpenStack to be a third world project,
> no good.
>
> OpenStack, could be the greatest cloud in the history of clouds, but to
> get there, you need me, to make sure our clouds are the greatest. We
> need to test the clouds, I'm talking about EXTREME cloud vetting,
> EXTREME cloud vetting. You know the other TC's are laughing at us,
> because we don't have such a great TC.
>
> The biggest problem we have is people rewriting parts of OpenStack in Go.
> They're bringing threads, they're compiled, with errors handled at the
> point of return, and some of them, I assume, are good programmers. So
> when I'm elected to the TC, I will build a wall, and make Go pay for it.
>
> ...
>
> Ok if you're still reading and you don't take things too seriously,
> then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
> serve you on the OpenStack Technical Committee. You may recognize me
> from various scalability and deployment discussions.
>
> OpenStack has a number of challenges that face it in the immediate. There
> is a crisis of identity that we're only just now wrapping our arms
> around, and a question about whether or not this should be something
> decided at a centralized level by the TC or not. Are we a toobox? Are
> we a product? Can we be both?  These are real things, and the TC should
> debate them. However, I don't think the TC should force the community to
> do anything it doesn't want to do as a whole. If the community really
> wants to end the big tent, we should listen, inform, and debate, and
> decide whether or not we think it is in the best interest to do so based
> on our own expertise, the experience thus far, and a plan to go forward.
>
> It is my personal belief that the big tent has largely been a success
> for OpenStack project teams, but created a problem of confusion that we
> should resolve. The recent efforts to more clearly define OpenStack have
> been positive, and I would like to help the TC continue down that road.
>
> In fact, I have recently started an Architecture Working Group to help
> define and shape what OpenStack is at a technical design level. Whether
> pieces have been evolved apart from one another, or specifically designed
> and built to spec, OpenStack hasn't done a good job of writing some
> of those things down. I believe the Architecture Working Group will
> be capable of improving that, and I want the TC to have some of that
> influence built in.
>
> So, if you want to see more design, consensus building, and an eye for
> scaling on the TC, then please consider casting a vote for me.

I nominate this email to be the best email ever sent to an OpenStack
list. In fact, I think we should replace the entire TC with this email.
This email shall be our leader and I, for one, welcome it gladly.

__
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 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

Re: [openstack-dev] TC Candidacy

2016-09-29 Thread Qiming Teng

I believe this is the voice we really need in the TC.
THANK YOU.

- Qiming

On Thu, Sep 29, 2016 at 11:47:12PM +, Jeremy Stanley wrote:
> I guess I'll send a copy of mine to the ML too, since all the cool
> kids seem to be doing it...
> 
> Most of you probably know me as "that short dude in the Hawaiian
> shirt and long hair." I'll answer to "Jeremy," "fungi" or even just
> "hey you." I'm starting my third cycle as PTL of the Infrastructure
> team, and have been a core reviewer and root sysadmin for
> OpenStack's community-maintained project infrastructure for the past
> four years. I've also been doing vulnerability management in
> OpenStack for almost as long, chaired conference tracks, and given
> talks to other communities on a variety of OpenStack-related topics.
> I help with elections, attend and participate in TC meetings and
> review proposed changes to governance. I have consistent, strong
> views in favor of free software and open/transparent community
> process.
> 
> https://wiki.openstack.org/user:fungi
> 
> I see OpenStack not as software, but as a community of people who
> come together to build something for the common good. We've been
> fortunate enough to experience a bubble of corporate interest which
> has provided amazing initial momentum in the form of able software
> developers and generous funding, but that can't last forever. As
> time goes on, we will need to rely increasingly on effort from
> people who contribute to OpenStack because it interests them, rather
> than because some company is paying them to do so. The way I see it,
> we should be preparing now for the future of our project:
> independent, volunteer contributors drawn from the global free
> software community. However, we're not succeeding in attracting them
> the way some other projects do, which brings me to a major
> concern...
> 
> OpenStack has a public relations problem we need to solve, and soon.
> I know I'm not the only one who struggles to convince contributors
> in other communities that we're really like them, writing free
> software under transparent processes open to any who wish to help.
> This skepticism comes from many sources, some overt (like our
> massive trade conferences and marketing budget) while others
> seemingly inconsequential (such as our constant influx of new
> community members who are unfamiliar with free software concepts and
> lack traditional netiquette). Overcoming this not-really-free
> perception is something we absolutely must do to be able to attract
> the unaffiliated volunteers who will continue to maintain OpenStack
> through the eventual loss of our current benefactors and well into
> stabilization.
> 
> Prior to OpenStack, I worked for longer than I care to remember as
> an "operator" at Internet service, hosting and telecommunications
> providers doing Unix systems administration, network engineering,
> virtualization and information security. When I first started my
> career, you couldn't be a capable systems administrator without a
> firm grasp of programming fundamentals and couldn't be a good
> programmer without understanding the basics of systems
> administration. I'm relieved that, after many years of companies
> trying to tell us otherwise, our industry as a whole is finally
> coming back around to the same realization. Similarly, I don't
> believe we as a community benefit by socializing a separation of
> "operators" from "developers" and feel the role distinction many
> attempt to strike between the two is at best vague, while at its
> worst completely alienating a potential source of current and future
> contributions.
> 
> What causes software to succeed in the long run is not hype,
> limitless funding or even technical superiority, it's the size and
> connectedness of its community of volunteers and users who invest
> themselves and their personal time. The work we're doing now is
> great, don't get me wrong, but for it to survive into the next
> decade and beyond we need to focus more on building a close-knit
> community of interested contributors even if it's not in the best
> interests of industry pundits or vendor product roadmaps.
> 
> OpenStack is people. If we lose sight of that, it's over.
> -- 
> Jeremy Stanley


__
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

Re: [openstack-dev] TC candidacy

2016-09-29 Thread John Dickinson

On 29 Sep 2016, at 16:00, gordon chung wrote:

>
> On 29/09/16 04:35 PM, John Dickinson wrote:
>>
>> I am concerned that there is a current focus on preserving the status
>> quo. There's focus on policies and rules instead of use cases; there's
>> focus on conformity instead of innovation; there's focus on forced
>> prioritization instead of inclusivity.
>
> i fully agree with this pov. there's a sentiment among certain members
> that if you choose a path different from the norm, you are not
> "following the OpenStack way".
>
> my question is (i guess this in theory could be ask to everyone), the
> the TC has historically been a reactive council that lets others ask for
> change and acts as the final approver (arguably, just my opinion). do
> you believe the TC should be a proactive committee that drives change?
> and if yes, to what scope? i realise the follow up is very open-end and
> vague and i apologise for this.

The TC is not small enough, and OpenStack is too big, for the TC to proactively 
drive and manage change across all OpenStack projects. In fact, I think 
OpenStack is too big for any one group to try to manage a task for all 
projects. I like how the docs team has been pushing docs into each project 
repository. That distributes the load and solves a scaling problem.

In my experience as a PTL for a single OpenStack project, I've learned that I 
can influence by suggestion, but I cannot mandate anything. In a large part, my 
role has been to respond to what the community is doing by removing any 
barriers that exist, monitoring the status of the team, connecting people 
working on similar tasks, and providing a general vision of where we're going 
as a project.

I see the role of the TC in much the same way. The TC should not be the 
high-priesthood of OpenStack where we go to present our supplications before 
we're allowed to do something. Individual projects should default to "doing" 
and the TC's role there is to make sure barriers for "doing" are removed. The 
individual projects are what initial and drive change in OpenStack, based on 
the needs of their specific users, and the TC aggregates those changes across 
projects to facilitate communication with the broader ecosystem about OpenStack 
in general.

I'm sure I could go on for quite a while about specifics I'd like to see. 
Here's a short list of bullets of things I'd love to see the TC take on:

 * Every project installable in 10 minutes or less.
 * Most projects independently installable to solve a specific use case for a 
deployer.
 * Track contributor activity to identify when and why people contribute. Is 
there some pattern that can be used to identify when someone might leave the 
community? Is there a pattern of how long-term contributors start? What are the 
major barriers for new contributors?
 * How do we reduce the average time a patch spends in review?
 * Why are people adopting OpenStack? If people move away from OpenStack (in 
whole or in part), what was missing in OpenStack?
 * What improvements can we make to facilitate team communication across time 
zones and across cultural lines?
 * How do we provide our corporate sponsors with a reasonably-accurate view of 
future development work?
 * How do we support new languages and deployment tools in OpenStack projects?
 * What improvements can we make to integrate proprietary software and hardware 
into our projects?
 * How does OpenStack work in a world where "cloud" is dominated by AWS, 
Google, and Microsoft?

etc.

--John

>
>>
>> If I am elected to the TC, I will look at every decision in the light
>> of these two needs. I will not focus on codifying rules, and I will
>> not focus on keeping OpenStack small and homogeneous. I will do what I
>> can to help the OpenStack community increase adoption today and remain
>> relevant as the industry changes.
>>
>
> yay to less codifying rules!
>
> cheers,
> -- 
> gord
>
> __
> 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

signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC candidacy

2016-09-29 Thread Monty Taylor

On 09/29/2016 06:14 PM, Clint Byrum wrote:
> https://review.openstack.org/379850
> 
> Let's make OpenStack great again.
> 
> If you don't know me, I'm very good. The code and designs I make
> are tremendous, and I intend to contribute to the TC bigly. The other
> candidates are sad, and they want OpenStack to be a third world project,
> no good.
> 
> OpenStack, could be the greatest cloud in the history of clouds, but to
> get there, you need me, to make sure our clouds are the greatest. We
> need to test the clouds, I'm talking about EXTREME cloud vetting,
> EXTREME cloud vetting. You know the other TC's are laughing at us,
> because we don't have such a great TC.
> 
> The biggest problem we have is people rewriting parts of OpenStack in Go.
> They're bringing threads, they're compiled, with errors handled at the
> point of return, and some of them, I assume, are good programmers. So
> when I'm elected to the TC, I will build a wall, and make Go pay for it.
> 
> ...
> 
> Ok if you're still reading and you don't take things too seriously,
> then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
> serve you on the OpenStack Technical Committee. You may recognize me
> from various scalability and deployment discussions.
> 
> OpenStack has a number of challenges that face it in the immediate. There
> is a crisis of identity that we're only just now wrapping our arms
> around, and a question about whether or not this should be something
> decided at a centralized level by the TC or not. Are we a toobox? Are
> we a product? Can we be both?  These are real things, and the TC should
> debate them. However, I don't think the TC should force the community to
> do anything it doesn't want to do as a whole. If the community really
> wants to end the big tent, we should listen, inform, and debate, and
> decide whether or not we think it is in the best interest to do so based
> on our own expertise, the experience thus far, and a plan to go forward.
> 
> It is my personal belief that the big tent has largely been a success
> for OpenStack project teams, but created a problem of confusion that we
> should resolve. The recent efforts to more clearly define OpenStack have
> been positive, and I would like to help the TC continue down that road.
> 
> In fact, I have recently started an Architecture Working Group to help
> define and shape what OpenStack is at a technical design level. Whether
> pieces have been evolved apart from one another, or specifically designed
> and built to spec, OpenStack hasn't done a good job of writing some
> of those things down. I believe the Architecture Working Group will
> be capable of improving that, and I want the TC to have some of that
> influence built in.
> 
> So, if you want to see more design, consensus building, and an eye for
> scaling on the TC, then please consider casting a vote for me.

I nominate this email to be the best email ever sent to an OpenStack
list. In fact, I think we should replace the entire TC with this email.
This email shall be our leader and I, for one, welcome it gladly.

__
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

Re: [openstack-dev] TC candidacy

2016-09-29 Thread gordon chung

On 29/09/16 04:35 PM, John Dickinson wrote:
>
> I am concerned that there is a current focus on preserving the status
> quo. There's focus on policies and rules instead of use cases; there's
> focus on conformity instead of innovation; there's focus on forced
> prioritization instead of inclusivity.

i fully agree with this pov. there's a sentiment among certain members 
that if you choose a path different from the norm, you are not 
"following the OpenStack way".

my question is (i guess this in theory could be ask to everyone), the 
the TC has historically been a reactive council that lets others ask for 
change and acts as the final approver (arguably, just my opinion). do 
you believe the TC should be a proactive committee that drives change? 
and if yes, to what scope? i realise the follow up is very open-end and 
vague and i apologise for this.

>
> If I am elected to the TC, I will look at every decision in the light
> of these two needs. I will not focus on codifying rules, and I will
> not focus on keeping OpenStack small and homogeneous. I will do what I
> can to help the OpenStack community increase adoption today and remain
> relevant as the industry changes.
>

yay to less codifying rules!

cheers,
-- 
gord

__
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

Re: [openstack-dev] TC candidacy

2016-09-29 Thread Chris Dent


On Thu, 29 Sep 2016, Flavio Percoco wrote:


I'm not saying it wouldn't be useful at all. What I'm saying is that
the format, and more importantly, the content will have to be studied.
I'll likely start working on this and I could use your help whether or
not you'll win the election
:)


Yeah, that sounds good. Please keep me involved.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] TC candidacy

2016-09-29 Thread Flavio Percoco


On 28/09/16 20:59 +0100, Chris Dent wrote:

On Wed, 28 Sep 2016, Jim Rollenhagen wrote:


+1 to release notes or something of that like. i was asked to give an
update on the TC internally and it seems the only information out there
is to read through backlog of meeting logs or track the items that do
get raised to ML. even then, it's hard to define what deliverables were
achieved in the cycle.



FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/


And the git tree, with a changelog, is here:
http://git.openstack.org/cgit/openstack/governance/


I assume, but I'd prefer if he confirm, that the point gordc was
trying to make was that there's more to what the TC gets up to than
merging changes to governance. That's certainly a major aspect and
one can track those changes by tracking both of those resources.

Part of the point I was trying to make in the message to which gordc was
responding is that whereas a git tree can allow someone to dig through
and acquire details, a thing that is more like release notes[1] is far
more human oriented and more likely to operate as a consumable digest of
what has happened. Notably a git log will not reflect important
conversations that did not result in a governance change nor activity
that could have led to a governance change but was rejected. Certainly
where a community says "no" is just as important as where it says "yes"?
Further, merged changes are changes that have already been decided. We
need more engagement, more broadly, while decisions are being
considered. That means being more verbose, sooner.

[1] Note that I don't actually think that release notes is the proper
form for some extra communication from the TC. Rather the justifications
that lead some projects to add release notes, in addition to the git
log, are something to consider for TC activity.


One thing that's been baking in the back of my head is to produce some sort of
summary of what the TC has done during the cycle. One reason I've not brought
this up is that I believe the information provided through the communication
subteam is probably more useful than a final write up and the end of the cycle.
In addition to this, the TC positions are 1 year long.

I'm not saying it wouldn't be useful at all. What I'm saying is that the format,
and more importantly, the content will have to be studied. I'll likely start
working on this and I could use your help whether or not you'll win the election
:)

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread gordon chung



On 28/09/2016 4:27 PM, Jeremy Stanley wrote:
> As was pointed out elsewhere in the thread, the TC has been trying
> to do something along these lines at
> http://www.openstack.org/blog/category/technical-committee-updates/
> but even with a dedicated communication subteam (see the May 13,
> 2015 entry) attempting to summarize important decisions, it's often
> a struggle to determine which items are important enough to include
> in a periodic high-level summary and which are administrivia better
> left buried in meeting minutes and review comments. All in all I
> think Anne and Flavio have done an awesome job with it.

agreed! thanks to all who did this. definitely useful for me rather than 
having to sift through meeting logs which often lack some context from 
discussions outside logs.

-- 
gord

__
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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread gordon chung



On 28/09/2016 3:59 PM, Chris Dent wrote:
> On Wed, 28 Sep 2016, Jim Rollenhagen wrote:
>
>> And the git tree, with a changelog, is here:
>> http://git.openstack.org/cgit/openstack/governance/
>
> I assume, but I'd prefer if he confirm, that the point gordc was
> trying to make was that there's more to what the TC gets up to than
> merging changes to governance. That's certainly a major aspect and
> one can track those changes by tracking both of those resources.
>
> Part of the point I was trying to make in the message to which gordc was
> responding is that whereas a git tree can allow someone to dig through
> and acquire details, a thing that is more like release notes[1] is far
> more human oriented and more likely to operate as a consumable digest of
> what has happened. Notably a git log will not reflect important
> conversations that did not result in a governance change nor activity
> that could have led to a governance change but was rejected. Certainly
> where a community says "no" is just as important as where it says "yes"?
> Further, merged changes are changes that have already been decided. We
> need more engagement, more broadly, while decisions are being
> considered. That means being more verbose, sooner.

Chris, i should let you speak for me. much more concise. :)

i wasn't really looking to track conflicts but that is definitely an 
interesting metric. more often than not, stuff happens without many eyes 
even seeing it.

personally, i was wondering if there was more beyond governance repo but 
it seems like that is workflow: propose patch, discuss at meeting, merge.

>
> [1] Note that I don't actually think that release notes is the proper
> form for some extra communication from the TC. Rather the justifications
> that lead some projects to add release notes, in addition to the git
> log, are something to consider for TC activity.
>

cheers,
-- 
gord

__
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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread Jeremy Stanley

On 2016-09-28 20:59:09 +0100 (+0100), Chris Dent wrote:
> Part of the point I was trying to make in the message to which gordc was
> responding is that whereas a git tree can allow someone to dig through
> and acquire details, a thing that is more like release notes[1] is far
> more human oriented and more likely to operate as a consumable digest of
> what has happened. Notably a git log will not reflect important
> conversations that did not result in a governance change nor activity
> that could have led to a governance change but was rejected. Certainly
> where a community says "no" is just as important as where it says "yes"?
> Further, merged changes are changes that have already been decided. We
> need more engagement, more broadly, while decisions are being
> considered. That means being more verbose, sooner.
[...]

As was pointed out elsewhere in the thread, the TC has been trying
to do something along these lines at
http://www.openstack.org/blog/category/technical-committee-updates/
but even with a dedicated communication subteam (see the May 13,
2015 entry) attempting to summarize important decisions, it's often
a struggle to determine which items are important enough to include
in a periodic high-level summary and which are administrivia better
left buried in meeting minutes and review comments. All in all I
think Anne and Flavio have done an awesome job with it.

Also, as you say, this mostly just covers decisions made and
discussions concluded rather than bringing attention to upcoming
topics or those for which deliberation was arrested pending
subsequent input. It's probably not the answer you're looking for,
but https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee and
https://review.openstack.org/#/q/project:openstack/governance+is:open
are remarkably effective to that end.
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread Doug Wiegley


> On Sep 28, 2016, at 1:59 PM, Chris Dent  wrote:
> 
> On Wed, 28 Sep 2016, Jim Rollenhagen wrote:
> 
 +1 to release notes or something of that like. i was asked to give an
 update on the TC internally and it seems the only information out there
 is to read through backlog of meeting logs or track the items that do
 get raised to ML. even then, it's hard to define what deliverables were
 achieved in the cycle.
 
>>> 
>>> FWIW, the resolutions that passed are listed here:
>>> https://governance.openstack.org/
>> 
>> And the git tree, with a changelog, is here:
>> http://git.openstack.org/cgit/openstack/governance/
> 
> I assume, but I'd prefer if he confirm, that the point gordc was
> trying to make was that there's more to what the TC gets up to than
> merging changes to governance. That's certainly a major aspect and
> one can track those changes by tracking both of those resources.
> 
> Part of the point I was trying to make in the message to which gordc was
> responding is that whereas a git tree can allow someone to dig through
> and acquire details, a thing that is more like release notes[1] is far
> more human oriented and more likely to operate as a consumable digest of

The minutes and logs exist.

http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html 


http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.log.html 


http://eavesdrop.openstack.org/meetings/tc/2016/ 




> what has happened. Notably a git log will not reflect important
> conversations that did not result in a governance change nor activity
> that could have led to a governance change but was rejected. Certainly
> where a community says "no" is just as important as where it says "yes"?
> Further, merged changes are changes that have already been decided. We
> need more engagement, more broadly, while decisions are being
> considered. That means being more verbose, sooner.
> 
> [1] Note that I don't actually think that release notes is the proper
> form for some extra communication from the TC. Rather the justifications
> that lead some projects to add release notes, in addition to the git
> log, are something to consider for TC activity.
> 
> -- 
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: 
> @anticdent__
> 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 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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread Chris Dent


On Wed, 28 Sep 2016, Jim Rollenhagen wrote:


+1 to release notes or something of that like. i was asked to give an
update on the TC internally and it seems the only information out there
is to read through backlog of meeting logs or track the items that do
get raised to ML. even then, it's hard to define what deliverables were
achieved in the cycle.



FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/


And the git tree, with a changelog, is here:
http://git.openstack.org/cgit/openstack/governance/


I assume, but I'd prefer if he confirm, that the point gordc was
trying to make was that there's more to what the TC gets up to than
merging changes to governance. That's certainly a major aspect and
one can track those changes by tracking both of those resources.

Part of the point I was trying to make in the message to which gordc was
responding is that whereas a git tree can allow someone to dig through
and acquire details, a thing that is more like release notes[1] is far
more human oriented and more likely to operate as a consumable digest of
what has happened. Notably a git log will not reflect important
conversations that did not result in a governance change nor activity
that could have led to a governance change but was rejected. Certainly
where a community says "no" is just as important as where it says "yes"?
Further, merged changes are changes that have already been decided. We
need more engagement, more broadly, while decisions are being
considered. That means being more verbose, sooner.

[1] Note that I don't actually think that release notes is the proper
form for some extra communication from the TC. Rather the justifications
that lead some projects to add release notes, in addition to the git
log, are something to consider for TC activity.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread Jim Rollenhagen

>> +1 to release notes or something of that like. i was asked to give an
>> update on the TC internally and it seems the only information out there
>> is to read through backlog of meeting logs or track the items that do
>> get raised to ML. even then, it's hard to define what deliverables were
>> achieved in the cycle.
>>
>
> FWIW, the resolutions that passed are listed here:
> https://governance.openstack.org/

And the git tree, with a changelog, is here:
http://git.openstack.org/cgit/openstack/governance/

// jim

__
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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread Steve Martinelli

On Wed, Sep 28, 2016 at 2:49 PM, gordon chung  wrote:

>
>
> On 28/09/2016 12:41 PM, Chris Dent wrote:
> >
> > * Information is not always clear nor clearly available, despite
> >   valiant efforts to maintain a transparent environment for the
> >   discussion of policy and process. There is more that can be done
> >   to improve engagement and communication. Maybe the TC needs
> >   release notes?
>
> +1 to release notes or something of that like. i was asked to give an
> update on the TC internally and it seems the only information out there
> is to read through backlog of meeting logs or track the items that do
> get raised to ML. even then, it's hard to define what deliverables were
> achieved in the cycle.
>
>
FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/



> i found this updates page[1] but it seemed a little sparse so i imagine
> other stuff happened. i think more of this would help explain what the
> TC does and where it hopes to go because to be frank, i'm not sure what
> is in the scope of TC and what is not and i've been following the list
> and meetings for a while.
>
> [1] http://www.openstack.org/blog/category/technical-committee-updates/
>
> cheers,
>
> --
> gord
>
> __
> 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 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

Re: [openstack-dev] TC candidacy

2016-09-28 Thread gordon chung



On 28/09/2016 12:41 PM, Chris Dent wrote:
>
> * Information is not always clear nor clearly available, despite
>   valiant efforts to maintain a transparent environment for the
>   discussion of policy and process. There is more that can be done
>   to improve engagement and communication. Maybe the TC needs
>   release notes?

+1 to release notes or something of that like. i was asked to give an 
update on the TC internally and it seems the only information out there 
is to read through backlog of meeting logs or track the items that do 
get raised to ML. even then, it's hard to define what deliverables were 
achieved in the cycle.

i found this updates page[1] but it seemed a little sparse so i imagine 
other stuff happened. i think more of this would help explain what the 
TC does and where it hopes to go because to be frank, i'm not sure what 
is in the scope of TC and what is not and i've been following the list 
and meetings for a while.

[1] http://www.openstack.org/blog/category/technical-committee-updates/

cheers,

-- 
gord

__
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

Re: [openstack-dev] TC Candidacy

2015-04-27 Thread Qiao, Liyong

+1

BR, Eli(Li Yong)Qiao

From: David Lyle [mailto:dkly...@gmail.com]
Sent: Thursday, April 23, 2015 8:57 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] TC Candidacy

I'm announcing my candidacy for the Technical Committee elections.

I have been contributing to OpenStack since Grizzly primarily in Horizon. I 
have also had the privilege to serve as Horizon PTL since Icehouse.

Why I'm running:

I believe there should be broader representation on the TC. We are growing the 
OpenStack ecosystem. Let's make sure horizontal teams and diverse parts of the 
ecosystem are represented more directly. I understand concerns of scaling were 
the reason for moving from the TC made up of all PTLs (I question that 
assertion), but the sacrifice so far has been diversity. I feel current TC 
members are exceptionally capable and take a broad viewpoint, but there are 
limits of how well that works. Let's represent broader swaths of our ecosystem 
in the technical leadership.

I think growing the OpenStack ecosystem is fantastic. As a developer and the 
PTL of a project that tries to span across most of that ecosystem it also 
worries me a bit too. I think we need to focus on how the newer and older parts 
of our ecosystem work together. How do we manage all the horizontal needs this 
introduces without going to the extremes of just scaling existing horizontal 
efforts because that won't work. And pushing all horizontal work on the 
individual projects is not appropriate because that yields chaos.

Finally, I believe the TC needs to be more active in guiding overall direction 
of OpenStack and problem resolution. I'm not suggesting a dictatorship of 
course. But let's set a direction, overall release goals for OpenStack and help 
enable and drive them.

I'm really proud to be a part of the OpenStack developer community, but I think 
we're facing some real challenges. We need to address some primary issues or 
this community will struggle to remain the vibrant, supportive place it is now.

Thank you,
David

__
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

Re: [openstack-dev] TC Candidacy

2015-04-24 Thread Luke Gorrie

On 23 April 2015 at 01:17, Maru Newby ma...@redhat.com wrote:

 My name is Maru Newby, and I am announcing my candidacy for the
 Technical Committee (TC) election.


Cool!

** Growing our contributors


Question regarding your candidacy:

If I recall correctly you have spoken in favor of face to face discussions
at mid-cycle meetings as a practical way to set priorities and move things
forward. What are your current thoughts on the costs and benefits of this?

Cheers,
-Luke
__
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

Re: [openstack-dev] TC candidacy

2015-04-24 Thread Tristan Cacqueray

Hi Edgar,

To make it clear, this candidacy can not be confirmed as it was received
after the deadline (April 23, 05:59 UTC).

Regards,
Tristan

On 04/24/2015 02:55 AM, Edgar Magana wrote:
 OpenStack Members,
 
 I would like to announce my candidacy to serve for first time on the 
 Technical Committee.
 
 Objective:
 
 I want to be part of the Technical Committee (TC) because I have all the 
 passion in the world for OpenStack and I want to keep dedicating my energy 
 and love to the most revolutionary opensource project of the last decade. I 
 want to make OpenStack the best platform from the software perspective but 
 also from the interconnectivity and operability sides as well.
 
 Experience:
 
 I have been member of OpenStack since April 2011, when I attended my first 
 summit in Santa Clara and since then I haven't missed one of them and I do 
 not want to do it! I am also part of the Neutron core team since 2012, 
 currently focus on getting ready the first OpenStack Networking Guide! Thanks 
 to all the support from the members of the Docs, Neutron and other teams. I 
 like to document everything about OpenStack deployments and best practices 
 for operability, some of my guides are referenced even by big companies like 
 Red Hat: https://www.rdoproject.org/Install#Installation
 
 Vision:
 
 I have spent many hours operating and developing OpenStack and I think it can 
 be better and better. It needs the right direction and the right support 
 without having vendor-specific interest impacting the future of the platform. 
 I want to bring the view of the operators to the TC. I want to give all this 
 passion and energy to this committee to ensure that we all going to keep 
 having all those great discussions every six months and many companies will 
 keep transitioning their Data Centers ADNs to be powered by OpenStack.
 
 Leading one of the most challenging OpenStack adoption in the Operators side 
 has given me the experience to guide the TC and the Foundation to the most 
 demanding areas in order to guarantee the growing of the teams and our 
 community.
 
 Sincerely,
 
 Edgar Magana
 -
 IRC: emagana
 Mail: emag...@gmail.com
 Github: https://github.com/emagana
 
 
 
 __
 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
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC Candidacy

2015-04-24 Thread Maru Newby


 On Apr 24, 2015, at 6:17 AM, Luke Gorrie l...@tail-f.com wrote:
 
 Question regarding your candidacy:
 
 If I recall correctly you have spoken in favor of face to face discussions at 
 mid-cycle meetings as a practical way to set priorities and move things 
 forward. What are your current thoughts on the costs and benefits of this?
 

I don't think our TC should be involved in a project's decision to hold a
mid-cycle unless legitimate complaints about the openness of the mid-cycle
remain unaddressed by the project's leadership.

My experience is that face-to-face communication can aid in building the
relationships and technical understanding essential to writing good software.
The drawbacks are that proximity can be both expensive and exclusionary.  I
think it's up to each project community to decide whether a mid-cycle is
justified, and if so, work hard to minimize the downsides.  Foundation support
is often available for those that can't afford to attend for financial reasons.
For those that otherwise can't attend, there is the option of encouraging
designation of a representative, ensuring that the mid-cycle is recorded or
logged, and deferring decision-making on explored options to the wider community
after the mid-cycle.


Maru
__
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

Re: [openstack-dev] TC Candidacy

confirmed

On 04/22/2015 09:32 PM, Michael Krotscheck wrote:
 Hi everyone!
 
 I'd like to announce my own candidacy for the OpenStack Technical
 Committee. My TL/DR platform is: Represent Front-End Engineering. It's
 what I do, it's what I love, it's what I've been doing for the last 15
 years, and it's what I want to keep doing for years to come.
 
 Would you like some details? Of course you would!
 
 *First: Represent Front-End Engineering on the TC.*
 
 To me, this means being an advocate to everyone who touches the things
 which people use to interact with OpenStack; CLI, Web UI, etc. From the
 engineers working on upstream projects such as Fuel, Refstack, Ironic-UI,
 Horizon, and StoryBoard, to the UI Developers downstream who are developing
 their own tools, I strongly feel this branch of our profession should be
 represented, and I would like to be that representative.
 
 *Second: Advocate ease-of-use across OpenStack.*
 
 I don't only mean pretty buttons - I also mean how easy the CLI clients
 are, how intuitive the API's are, and how easy it is to onboard and/or
 support your own engineering efforts. You can have all the feature support
 in the world, but if it's not easy to use, you're doomed out of the gate.
 
 *Third: Make JavaScript a first-class citizen.*
 
 Yep, _this_ can of worms! Between the projects mentioned above, it's pretty
 clear that JavaScript is here to stay. With that in mind there remain many
 problems with the tooling, and we need to be conscious of those
 shortcomings as we start to draft policies that support the needs of all
 stakeholders: OpenStack's components, Engineers both downstream and
 upstream, Package Maintainers, and most importantly Operators and their
 Customers.
 
 *My qualifications:*
 
 I've been active in the OpenStack community for about 18 months now,
 working on Monty Taylor's team here at HP on trying to get StoryBoard to
 the point where it can replace Launchpad. I'm more-or-less responsible for
 all things NodeJS, NPM, Selenium, and Browser on infra, basically
 everything you need to build and test a Web UI. I've recently landed
 supporting technologies (such as CORS) that will greatly assist in
 unleashing downstream UI developers post-liberty, and am trying to teach
 Infra how to publish javascript libraries much like it does for python.
 Also, I've got 15 years of experience as a UI engineer, and a scant year of
 experience as a UX researcher.
 
 Michael Krotscheck
 
 
 
 __
 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
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC candidacy

confirmed

On 04/22/2015 09:52 PM, Mark McClain wrote:
 All-
 
 I'd like to announce my candidacy to continue serving on the Technical 
 Committee.
 
 
 Platform
 —
 OpenStack is a growing community comprised of many parts and we we must view 
 ourselves as one unit. As a TC member, I will continue to place the interests 
 of the larger community over those of those of individual projects.
 
 There are several key areas I'd like to see the TC focus:
 
 Development
   The Technical Committee should serve as a high level forum to facilitate 
 defining cross project technical and procedural requirements. While many of 
 our programs share commonalities, there are still too many differences in 
 policies and technical decisions. The addition of cross project 
 specifications is a step towards unifying the development process and design 
 standards within our community.  As we accept more projects under the new 
 governance model, the TC should work to facilitate developer mobility across 
 projects by promoting best practices.  Increased mobility will strengthen our 
 community as it helps to prevent silos. Reviews are an another area the TC 
 should focus on during the upcoming cycle. The TC should review and work with 
 projects to improve the contributor and reviewer experience when contributing 
 to projects both big and small.
 
 Cross Project Communication
   Our codebase has grown significantly over the years and a contributor must 
 invest significant time to understand and follow every project; however many 
 contributors have limited time must choose a subset of projects to direct 
 their focus.  As a result, it becomes important to employ cross project 
 communication to explain major technical decisions, share solutions to 
 project challenges that might be widely applicable, and leverage our 
 collective experience.  The TC should seek new ways to facilitate cross 
 project communication that will enable the community to craft improvements to 
 the interfaces between projects as there will be greater familiarity between 
 across the boundary.
 
 Unified Experience
   For OpenStack to be successful we must strive to provide a unified 
 experience for both users and deployers. During the previous cycles we have 
 made progress in this area, but there is still work to be completed. When 
 visiting user groups, a common thread during discussion is the installation 
 experience. The TC should identify common installation configurations and 
 work with projects to optimize installation and upgrades.  Equally important 
 is the users. The TC should work to promote and support projects such the 
 OpenStack client and SDK which aim to provide users with tools that are well 
 maintained, documented and easy to use. Our community has invested 
 significant effort to improve this experience and this should remain a focus 
 going forward.
 
 
 About Me
 ——
 I have served on the Technical Committee for last two years and I am a former 
 PTL. Believing that OpenStack is a unified community, I have contributed code 
 and reviews to many of our projects since Sent from my iPad
 
 We have built a very special open community through the contributions of 
 many.  These contributions have powered our phenomenal growth and I'm excited 
 about our future!
 
 Thanks,
 mark
 
 __
 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
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC Candidacy

confirmed

On 04/23/2015 12:26 AM, David Medberry wrote:
 Announcing my candidacy for the TC.
 
 I would bring an operator's perspective (ie, operator, user, super-user and
 dev) to the Technical Committee.
 
 I've been involved in OpenStack for four years. I gave talks at San Diego,
 Atlanta, Paris, and soon Vancouver as a contributor, community organizer,
 and operator.
 
 I would consent to serve a single term.
 
 -dave
 
 
 
 __
 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
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC Candidacy

confirmed

On 04/23/2015 12:56 AM, Maish Saidel-Keesing wrote:
 I would like to announce my candidacy for the OpenStack Technical Committee
 
 Many of you many not know me, because I am not a very active contributor.
 
 First a bit about myself. I am a Platform Architect working for Cisco in
 Israel and have been involved with OpenStack for the past two years. I
 was and (and still am a very active member of the virtualization
 community [1] and have been for a good number of years.
 
 I was honored to contribute and participate in the OpenStack
 Architecture Design Guide [2]. I am not new to writing but this was a
 new experience for me. One that I thoroughly enjoyed and would love to
 do again, if presented with the opportunity.
 
 These are the following reasons I think I can make a difference as part
 of the TC
 
 #1 Diversity
 
 The vast majority of the TC members are all long standing and well known
 members of the OpenStack community. Many of them have been
 core-developers, PTL's, reviewers. All of them have one thing in common
 they are developers and people who take pride and joy in contributing
 code to the OpenStack projects.
 
 I too have contributed code to the OpenStack projects - but not on the
 scale that any of the other candidates have. nowhere near close.
 And I am not ashamed of that fact.
 I am not a developer. Yes, I dabble in code (not as much as I would
 like), but I am deep down in my heart, an Operations guy.  I like to get
 things to work, but not only that they work, but that they are stable,
 robust, and will provide a sound infrastructure (so that I do not get
 paged at 03.00 every night because something fell over and died).
 When all of the members of a committee are from a single 'stream' then
 it is natural to look at things in a certain way. But that is not the
 only way to look at things, there are other perspectives that need to be
 considered and that perspective (in my humble opinion) is missing.
 
 
 #2 Focus
 
 There has been a lengthy discussion over the past few months about what
 OpenStack is and what it is not. What should be part of OpenStack and
 again what should not. I cannot say that I fully agree with all the
 decisions that have been made, although I do fully agree with the
 direction in which OpenStack is going and how the TC has been driving that.
 
 I feel that the as part of the TC I will help the community focus on
 building a tightly integrated suite of software (there is no way you can
 call OpenStack a product) that will work, and work well [3].
 
 
 #3 Acceptance of others
 
 It is no secret that i think that I have spoken my mind[4], more than
 once on how I find it extremely hard for someone who is not a developer
 to help and make OpenStack better. I have tried to lower that hurdle in
 a number of ways [5] to make it easier for 'non-dev's' to starting
 'chipping in'. But it seems that I was not successful. Even with regards
 to myself.
 
 We are all members of the community. But there are several levels. Even
 in this election only ''Individual Members who committed a change to a
 repository under ’any’ of the official OpenStack Project Teams (as
 defined above) over the last two 6-month release cycles are
 automatically considered ATC'' and they are the only ones that can vote.
 
 There are other ways to contribute.
 People that report bugs contribute.
 People that write blog posts contribute.
 People that evangelize in User groups and speak at conferences, meetings
 etc. - they also contribute.
 
 It is not all about code.
 Yes it is hard to quantify. Yes it is hard to measure. But that does not
 mean it should not be considered.
 
 If elected to serve as part of the TC - this is something I would like
 pursue - something that can make the OpenStack community not only a
 developer community - but a community of all those who care about it.
 
 I would like to leave you with one last thought.
 I thought long and hard about putting up myself as a candidate. I do
 think that I have a fresh perspective to bring to the table, a different
 way of looking at things and a lot of passion that can help OpenStack
 achieve what it set out to do.
 
 ``Our goal is to produce the ubiquitous Open Source cloud computing
 platform that will meet the needs of public and private cloud providers
 regardless of size, by being simple to implement and massively scalable.``
 
 I would like to wish all the candidates the best of luck.
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC candidacy

confirmed


On Wed, Apr 22, 2015 at 9:46 AM, Anita Kuno ante...@anteaya.info wrote:
 Please consider my candidacy for membership on the technical committee.

 My name is Anita Kuno. I consider my home project to be Infra but I tend
 to move around wherever I feel the need is greatest.

 I have worked on OpenStack since mid-grizzly starting as an intern with
 the GNOME Outreach Program for Women (which is now known as Outreachy)
 with my mentor Iccha Sethi. I moved around until I found Infra and have
 considered that my home base ever since, mostly because Infra, and my
 job, allows me so much flexibility.

 During the Hong Kong summit I launched myself into Neutron to see if
 there was anything I could do to support improvement, not because I knew
 anything about Neutron but because I live by the axiom don't ask anyone
 to do anything you wouldn't be prepared to do yourself. I realized that
 Neutron developers couldn't even find each other to talk to each other
 due to the crowd and organized a Neutron Tempest code sprint in Montreal
 in January 2014.

 Coming out of that, I have been involved with the third party ci space
 ever since, a difficult and demanding space and those involved with have
 many opinions on whether I have done and am doing a good job or a poor job.

 I split the project-config repo out of what was the Infra config repo
 (and is now system-config) at the end of Juno and have been a core
 reviewer on the project ever since. I was able to help Neutron split out
 their 'as a service' repos at the Sprint in Lehi in December last year
 due to having repo-split experience myself.

 I had known that the Nova-net to Neutron migration work was/is important
 and had attended the Paris summit session on the issue, which had some
 people indicate they would drive the work so stepped back believing it
 was taken care of. Until December when I saw that not enough work had
 taken place for anything to happen in Kilo. I got involved to support
 Oleg Bondarev's work and help find more people to provide design
 direction and feedback. We had a design and got some code written (way
 to go group) however the feedback from the ops summit was such that it
 became evident that the current solution even if finished would be
 insufficient to address the issue. I curtailed our work (with agreement
 of those at the meeting) in favour of opening a larger discussion on the
 mailing list. I consider the work those involved put in to be valuable,
 as it is possible we might not have gotten the level of detail in the
 feedback we currently have without the code, thank you to all who
 participated.

 At present I have agreed to chair the discussion in Vancouver for the
 session addressing Nova-net and Neutron. I ask that those involved and
 affected by this work find it in their hearts to bring a positive
 outlook to this issue. I'm grateful for your support.

 Last cycle I attended the Neutron, Keystone, Nova and Cinder mid-cycles,
 to help with third party work, the nova-net to neutron migration as well
 as helping project devs better understand how infra works and how to
 maximize efficient use of infra tools such as gerrit as well as how to
 offer an elastic-recheck fingerprint.

 I tend to gravitate towards work that needs to get done but which noone
 else wants to do. I have been operating from the belief that this is for
 the benefit of OpenStack. I will admit the big tent movement has thrown
 me off in regards to what is beneficial for OpenStack. Thierry's blog
 post helps in that regard. I would like to look and work on issues that
 affect the health of OpenStack long term including our vision of our
 targeted user.

 I am an astrologer at heart and as such look at large patterns and
 cycles of activity as well at their results. OpenStack is in a unique
 position to redefine software creation as a process that has outcomes
 that can be negotiated as beneficial for all concerned. The way it does
 so is by incorporating unlimited freedom with careful evaluation of
 structure and limits of resources by balancing culture and social
 responsibility to seeing and respecting both ends of the spectrum in
 actions. When we do this (and we have been able to) then everyone wins
 and feels nourished as a result. When one side of OpenStack (the freedom
 side, for instance) needs to accomplish its goal at the expense of the
 other side (careful evaluation of structure and limits of resources)
 then we all lose. It is a powerful energy structure and requires balance.

 I also served the technical committee as election official for 4
 election seasons. I want to thank you co-election officials for your
 guidance and support in that process, Monty Taylor, Thierry Carrez and
 Tristan Cacqueray (who is currently serving as an election official). I
 would also like to acknowledge Elizabeth K. Joseph who has replaced me,
 thank you to you as well, Elizabeth.

 Please feel free to ask me any questions if my post has failed to

Re: [openstack-dev] TC candidacy

confirmed


On Wed, Apr 22, 2015 at 9:43 AM, Dean Troyer dtro...@gmail.com wrote:
 Hello OpenStack world! My name is Dean Troyer and I am running for the
 OpenStack Technical Committee.

 I have been part of the OpenStack community for a long time and heavily
 involved in three projects: I was an early contributor to DevStack and
 served as its PTL during its short tenure as a stand-alone program, I
 started Grenade to use DevStack as the basis for upgrade testing. I also am
 the PTL of the OpenStackClient project that recently became the first
 project brought into the expanded official project definition.

 The common thread of my work in OpenStack has been with things that cross
 the traditional vertical service projects. This has highlighted the scope
 and consequences of differences between projects for me. Differences that
 affect project developers is one thing, and sometimes a good thing even, but
 differences that adversely affect deployers and consumers of OpenStack
 clouds is another thing altogether. I believe this is where the focus of
 encouraging projects to converge should be placed. Efforts like the API
 Working Group and the Log Working Group need to be encouraged where they
 improve the experiences of our customers (where 'our' == 'OpenStack' and
 'customers' == 'everyone downstream from OpenStack').

 I believe the TC has a good bit of work ahead to follow through implementing
 the vision of inclusiveness. Communicating the state of projects is a huge
 part of this. We should set up the goals and see who can score. Those
 projects that do score will be the ones rewarded not by the TC but by the
 rest of the community. One specific example that I think the TC should
 facilitate is describing the technical relationships between projects. The
 TC should bless, if not create, a common vocabulary to describe the groups
 of projects and their relationships. While this may be expressed in 'tags',
 it is more than just tag definitions.

 The Technical Committee is unique in that in some way it touches every
 aspect of OpenStack: projects and project developers, application
 developers, distributors and VARs, cloud deployers and operators, end users,
 and the OpenStack Board of Directors (DefCore!). The TC is the duct tape of
 OpenStack! No, it is better than that, it is by design the group that
 oversees enabling everything else to succeed.

 I believe that TC members must have a broad vision and insight into many
 parts of OpenStack and depth into at least a couple of areas. And I believe
 that I have both of those attributes. I would appreciate your consideration
 and vote.

 As I mentioned above, I have been part of the OpenStack community since
 before there was one, working on the original Nova deployment at NASA. That
 was followed by a stint at Rackspace where DevStack and OSC were born, and
 on to Nebula where we tossed Grenade into the world. After the recent events
 at Nebula I will be joining Intel soon and again be focused on upstream
 OpenStack projects.

 Thanks again for your time and consideration
 dt

 --

 Dean Troyer
 dtro...@gmail.com

 __
 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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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

Re: [openstack-dev] TC Candidacy

confirmed


On Wed, Apr 22, 2015 at 5:24 AM, Ed Leafe e...@leafe.com wrote:
 Greetings Stackers!

 I'm announcing my candidacy for the Technical Comitee Elections.

 Those of you who have been around OpenStack for a while know me, as I was one 
 of the original developers involved since the inception of OpenStack back in 
 2010, when I worked for Rackspace's Cloud Server team. I was a contributor 
 and core reviewer for Nova until a job change at Rackspace removed me from 
 direct OpenStack development around the Essex release. I was still 
 peripherally involved, though, as my work as a Developer Advocate involved 
 creating the first Python SDK for OpenStack [0], which gave me a great 
 education on how frustrating inconsistent APIs can be! In order to help 
 improve the experience of developers building apps with OpenStack, I 
 wholeheartedly support the efforts of the API Working Group to reduce this 
 problem in the future.

 [0] https://github.com/rackspace/pyrax

 Fast-forward to last September, when I joined IBM with one mandate: work 
 full-time on OpenStack by contributing as much as possible to upstream 
 OpenStack, and becoming involved in the community. Since then I've 
 re-immersed myself in Nova, focusing mainly on the effort to clean up the 
 Scheduler interfaces. So I believe that this history gives me a unique 
 perspective on OpenStack development: where it came from, and where it needs 
 to go to move forward.

 I mentioned improving the experience of developers working *with* OpenStack; 
 I'd also like to improve the experience of developers working *on* OpenStack. 
 To that end, I agree wholeheartedly with Thierry's call to step out of the 
 way [1]. There is a lot of energy across the many projects, and the TC 
 should do everything it can to help make that energy effective without 
 stifling it. I spoke about the potential for OpenStack to change the world 
 in an interview I gave for Rackspace last year [2], and the last thing I 
 would want to see is someone with an idea get discouraged because there were 
 too many hoops to jump through to make it happen on OpenStack.

 [1] http://ttx.re/stepping-out-of-the-way.html
 [2] https://youtu.be/0QRkzMW3OdA?t=115

 One place, though, where I think the TC can inject itself is to help 
 alleviate the lack of core reviewers, particularly in Nova, which I discussed 
 in [3]. Having so few cores for the number of patches being created is simply 
 not sustainable, and just wishing for things to get better isn't cutting it. 
 And I do consider it a technical problem, since the main barrier isn't lack 
 of interested people; it's that it's currently too difficult for most people 
 to learn enough about all the various parts of the project necessary to 
 achieve core status.

 [3] http://blog.leafe.com/the-core-deficiency

 I sort of wish that there was the questionnaire format like we had in the 
 last TC election, so I could be sure to give everyone a clear view on where I 
 see things on different issues. If you have any such concerns, please feel 
 free to respond to this email (and to those of the other candidates!), and I 
 will be happy to answer any questions.

 Thanks for your consideration,

 -- Ed Leafe






 __
 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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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

Re: [openstack-dev] TC Candidacy

confirmed


On Wed, Apr 22, 2015 at 11:19 AM, Zane Bitter zbit...@redhat.com wrote:
 Hello Stackists,
 I'd like to announce my candidacy for the OpenStack Technical Committee.

 I'm running because I don't think that the diversity of perspectives amongst
 TC members reflects the diversity of our community. We're fortunate to have
 a few people whose brilliance often transcends the scope of their day-to-day
 focus, but I don't think that can outweigh the fact that (by my, arguable,
 count) 12 out of 13 are focused primarily on Nova and the projects
 (including cross-project efforts) that evolved directly out of it.

 When a group of people share a common vision and goal, they can pretty much
 always figure out a way to work together toward it. When they don't, they
 have to invent rules and structure and bureaucracy to keep everyone in
 line.[1] I... think we need to work more on the vision thing ;) Thierry
 calls it 'stepping out of the way', but I think of it as stepping up, out of
 the weeds, to look at the bigger picture.

 My hope is that in a decade or two, developers will prefer to write their
 new applications against Open Source implementations of open APIs - and not
 just to avoid lock-in, but because they'll be as good or better than
 proprietary alternatives. Linux has already made that a reality at the level
 of individual servers - and while offering refuge from proprietary Unixes
 (Unices?) for legacy applications was no doubt a critical (and lucrative)
 part of getting there, it's much more important in the long run that it's
 also the preferred platform for new development. Today a growing fraction of
 applications are bigger than a single server, and I believe that OpenStack
 represents our best opportunity to make sure that in the future open source
 cloud APIs will be the preferred choice too.

 The big tent is a great start - it allows a project to assure contributors
 that they are committed to truly open[2] governance long before it matures
 to the point where it could have been incubated under the previous process.
 And after all, the most powerful technologies we've developed are social,
 and we shouldn't be reluctant to use them. However, if only a small section
 in the middle of the tent is waterproof, then the big tent exists in name
 only. We have to make sure we continue to help and guide all of the projects
 as they grow and mature - getting them in the tent is only the first step. I
 am strongly opposed to the TC using the tagging system to identify use cases
 it thinks are important - the community can and will decide for itself what
 is important. (Of course I support using the tagging system to provide more
 information that the community can use to evaluate projects for themselves,
 and more long-form documentation of use cases where that is lacking.) I
 believe in abundance, not scarcity: when our community provides space for
 participants to work on problems they care about we don't weaken the
 existing projects, we actually strengthen the community by increasing its
 critical mass. (In other words, we may have a task-allocation problem, but
 we shouldn't mistake it for a project-allocation problem since it will
 require different solutions.)

 Right now we're missing a lot of fundamental building blocks - like
 user-configurable authorisation, and public-facing asynchronous messaging -
 that we need to allow workloads running in a cloud to interact with it. As a
 result, a lot of projects that should be tightly (small-i) integrated (but
 loosely coupled!) with each other are developing in an ad hoc manner, and a
 lot of technical problems are being solved over and over, often badly. The
 pre-big-tent regime gave an incentive to new projects not to work together,
 and we need to reverse that effect. The TC needs to boost the confidence of
 OpenStack developers to simplify things by taking dependencies on other
 projects where appropriate, and I think the best way to do that is to kick
 off an ongoing discussion about the vision for and design of OpenStack at a
 level above that of indivudual projects. (We've made a good start on
 cross-project co-ordination at a _lower_ level, like the API working group,
 but to do so at a higher level will require the TC's blessing.)


 In case you don't know me, I'm a core developer of Heat and I've been
 involved in OpenStack since the Heat project kicked off about 3 years ago.
 I'm also a former elected PTL, and I've been working closely with the TC
 since Heat applied for incubation back around the time of the Grizzly
 summit. I've attended most TC meetings for at least the past 18 months, so
 I'm already up to speed with what has been happening. Finally, I currently
 lead a team at Red Hat developing (upstream!) tools for updating OpenStack
 deployments - which is another way of saying that few people are more
 motivated to make deployment easier than I ;)

 Thanks for reading this far. Please make time to read the other

Re: [openstack-dev] TC Candidacy

confirmed


On Wed, Apr 22, 2015 at 5:05 PM, Sergey Lukjanov slukja...@mirantis.com wrote:
 Hi folks,

 I'd like to announce my candidacy for the TC elections.

 Here is a list of the main directions I would like to concentrate on as a TC
 member:

 * Continue to grow the OpenStack long-term vision and inclusive approach
 that comes with The Big Tent. We should not just be more inclusive, but
 also provide new OpenStack projects with fine-grained directions for
 improvements, recommendations and cross-project coordination.

 * Strengthen the voice of the platform projects (Heat, Sahara, Murano, etc)
 on the Technical Committee.

 * Bring additional focus and attention to OpenStack end users of all levels,
 especially application developers who are the most active cloud users.

 * Help OpenStack community newcomers better understand the process of
 contributing, learning the upstream tooling, and finding answers to their
 common questions.

 * Allow more self-governance and automation of common tasks like adding new
 source repositories without TC pre-approval.

 A few words about me. I have been actively involved in OpenStack community
 for the last 2.5 years. I'm PTL of OpenStack Data Processing service
 (Sahara) from its very beginning and a core team member of the OpenStack
 Infrastructure team. Before OpenStack, I was involved in other open source
 projects including Apache/Twitter Storm, Kotlin and Big Data solutions. I'm
 currently leading the Sahara team and an internal OpenStack Infra clone
 initiative at Mirantis.

 Thanks.


 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.

 __
 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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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

Re: [openstack-dev] TC Candidacy

confirmed


On Wed, Apr 22, 2015 at 4:17 PM, Maru Newby ma...@redhat.com wrote:
 My name is Maru Newby, and I am announcing my candidacy for the
 Technical Committee (TC) election.

 tl;dr;

 I'm a relative unknown outside of Neutron, but I've been helping to drive
 high-level change in that project. I would welcome the opportunity to bring my
 energy and dedication to OpenStack-wide concerns as a member of our TC.

 If you're willing to read any part of this email, I hope it would be 'Why vote
 for me?'.

 If not, and you are as frustrated with the status quo as I am, I hope you will
 consider voting for candidates that support the goal of building a more 
 engaged
 TC focused on ensuring that participation in OpenStack becomes more enjoyable
 and sustainable.

 Thank you for reading, and make sure to vote!


 * Why vote for me?

 If elected, I'm going to be a squeaky wheel advocating for anything and
 everything that empowers our development community to deliver useful software
 into the hands of users.  If this puts me at odds with those that want to 
 focus
 on issues like 'What is OpenStack' or 'How can we systematize project culture 
 to
 make it easier to communicate?', good!  I believe that you, as a technical
 contributor to OpenStack, need stronger representation of your viewpoints on 
 our
 TC, and I'm one of the strongest advocates you're likely to find in this
 community.  I am currently employed full time upstream, and I am willing and
 able to devote the resources necessary to do justice to the role.

 I also intend to advocate for focusing the OpenStack community on ambitious, 
 but
 achievable, goals.  I believe this will require making hard choices about 
 which
 use cases we can reasonably expect to support.  To me, the idea that OpenStack
 can be all things to all people is dangerous.  It's just as likely that in
 trying to do it all, we do little of it well, and risk irrelevance.  I think 
 our
 primary competition is and will continue to be proprietary cloud, and my 
 biggest
 fear is that we become unable to compete on cost due to the operational
 complexity required to make everyone happy.  We need to keep our collective 
 eyes
 on the ball!

 To be clear, I want to be a part of a TC with as diverse a group of viewpoints
 as possible to ensure that we have to work hard to achieve consensus.  If
 agreement is reached too easily, there is probably something wrong.  My 
 wanting
 to push a developer-centric agenda doesn't mean that I don't respect the need 
 to
 address other issues.  My voice would be one of many, and I recognize that
 consensus requires compromise.


 * Why not vote for me?

 There are candidates more deserving of your vote if you think our TC shouldn't
 have a role in providing leadership to the OpenStack community.  If you 
 believe
 that our TC is already sufficiently developer-focused, then I also don't 
 deserve
 your vote.

 This is in no way to suggest that I want to see our TC become a top-down
 decision-making body. This is still an open source project, after all, and I
 know first-hand the complexities of the culture involved.  I do think it
 appropriate, though, for an elected body with as much visibility as our TC to
 participate more actively in addressing the challenges we face.


 * Key concerns

 There are any number of issues facing OpenStack today, but the items on the
 shortlist that follows are the concerns that I would like to see the TC
 champion in the near-term:

 ** Scaling our development effort

 The stated goal of our TC of late has been to 'get out of the way'.  I
 wholeheartedly support this intention, and would like to see it extended to 
 how
 our TC approaches governance beyond project evaluation.  I think our TC should
 be responsible for proposing what we want to achieve rather than in how we
 should achieve it.  Outcomes, rather than process.  I think project-level
 contributors are best equipped to solve the problems of implementation.  Our 
 TC
 can take responsibility for setting OpenStack-wide expectations and in
 facilitating - rather than managing - cross-project advancement towards these
 goals.  More than ever, we need to be pulling in the same direction, and I 
 think
 our TC is an obvious candidate to rally ourselves around.

 I hope we all recognize that we can't scale OpenStack if decisions are
 constantly gated on a small group of 'tastemakers'.  Delegation of trust is
 required, whether at the level of our TC or the individual projects.  I think 
 we
 need to take our TC's recent momentum to the project level and find ways to
 increase delegation of responsibility.  Nova and Neutron, for example, have 
 had
 to face ever-increasing demands with the same small pool of core reviewers, 
 and
 many of you know all-too-well the pain that has resulted.  Core reviewers - 
 like
 the pre-big tent TC - have inadvertently become micromanagers as their
 responsibilities have evolved beyond their capacity to meet them.  The

Re: [openstack-dev] TC Candidacy

confirmed


On Wed, Apr 22, 2015 at 5:56 PM, David Lyle dkly...@gmail.com wrote:
 I'm announcing my candidacy for the Technical Committee elections.

 I have been contributing to OpenStack since Grizzly primarily in Horizon. I
 have also had the privilege to serve as Horizon PTL since Icehouse.

 Why I'm running:

 I believe there should be broader representation on the TC. We are growing
 the OpenStack ecosystem. Let's make sure horizontal teams and diverse parts
 of the ecosystem are represented more directly. I understand concerns of
 scaling were the reason for moving from the TC made up of all PTLs (I
 question that assertion), but the sacrifice so far has been diversity. I
 feel current TC members are exceptionally capable and take a broad
 viewpoint, but there are limits of how well that works. Let's represent
 broader swaths of our ecosystem in the technical leadership.

 I think growing the OpenStack ecosystem is fantastic. As a developer and the
 PTL of a project that tries to span across most of that ecosystem it also
 worries me a bit too. I think we need to focus on how the newer and older
 parts of our ecosystem work together. How do we manage all the horizontal
 needs this introduces without going to the extremes of just scaling existing
 horizontal efforts because that won't work. And pushing all horizontal work
 on the individual projects is not appropriate because that yields chaos.

 Finally, I believe the TC needs to be more active in guiding overall
 direction of OpenStack and problem resolution. I'm not suggesting a
 dictatorship of course. But let's set a direction, overall release goals for
 OpenStack and help enable and drive them.

 I'm really proud to be a part of the OpenStack developer community, but I
 think we're facing some real challenges. We need to address some primary
 issues or this community will struggle to remain the vibrant, supportive
 place it is now.

 Thank you,
 David


 __
 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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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

Re: [openstack-dev] TC candidacy

confirmed


On Wed, Apr 22, 2015 at 1:13 PM, Armando M. arma...@gmail.com wrote:
 I would like to announce my candidacy for the OpenStack Technical Committee.

 I will try to be brief and to the point: I have been involved in OpenStack
 since the early days of the Austin release; I have worked on (perhaps) the
 two most prolific projects in OpenStack (Nova, and Neutron) and a few others
 aimed at ensuring their quality (Tempest, DevStack, and the infra ones). I
 have been mainly a developer, but also a deployer, distributor, user, tech
 writer, you name it.

 Under these points of views I have seen friction in dealing with OpenStack
 increase over time, and I want to do something about it. I have never run
 for the TC before, or any other position of 'influence'.  I came to the
 realization that doing something about it by being on the fringes could only
 get me so far.

 My main goal is to empower the developer, allowing him/her to go at the pace
 he/she is comfortable with, whilst preserving the quality of software being
 produced: I believe we have many bottlenecks and inefficiencies in the way
 we develop and consume OpenStack technologies. In Neutron I, with the help
 of others, have tried to identify these and proactively did something about
 it: decomposing the codebase in core vs plugins and moving away from the
 project reliance on Tempest to ensure stability are examples to name a few.

 At the same time decentralizing and increasing speed of development can
 impair coherence and cohesion of the overall solution and that is why I
 think a seat in the TC would give me enough exposure to help preserve, and
 strive to achieve these qualities in the software we build. The OpenStack
 ecosystem is incredibly diverse and yet we need each technology developed
 under its umbrella to share a lot more than the four Opens. The definition
 of shared methodologies, practices and guidelines can help us achieve that,
 but most importantly a shared roadmap that can let us peek into the future
 of OpenStack as a whole rather than a fragmented collection of services that
 work poorly together.

 Thanks for reading.

 Regards,
 Armando

 __
 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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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

Re: [openstack-dev] TC candidacy

2015-04-22 Thread Tristan Cacqueray

confirmed

On 04/22/2015 05:26 AM, Julien Danjou wrote:
 Hey fellow developers,
 
 I'd like to announce my candidacy for the Technical Committee election
 that's happening.
 
 
 TL;DR: Vote for me to bring back the fun and raise the bar! :)
 
 
 As you might know, I've been a member of the OpenStack community for
 several years now, and I actually already seated at the TC, back when
 PTL had a seat. I've been leading Ceilometer for a while, and I'm still
 active in this project, as I recently started and pushed Gnocchi¹ in
 OpenStack. I contribute also to Oslo and other OpenStack projects for a
 very long time now.
 
 Let's jump to the hot topics.
 
 The TC decided to open the gates for what goes into OpenStack, and
 that's great, as trying to control that was totally failing.
 Now there's a work ongoing about classifying projects under tags, and
 I've absolutely no idea why the TC should be responsible for this
 ultimately. This really looks like something that could be built and
 decided by the entire community. I don't think I want to spend too much
 time on this anyway.
 
 I think OpenStack has way too much bureaucracy. The whole project is
 glued in tons of processes that slows everything down for little value.
 I see people writing code that is refused because there's no spec, specs
 not reviewed because there's no code, and people frustrated because they
 have to wait 3 months to have a brain-dead one-liner fix to get merged.
 While I recognized there are some upside to this processes, this has
 gone too far and I want OpenStack to become more agile (there, I said
 it).
 
 I've pushed the idea recently in Gnocchi that the bar should be raised
 about documentation. We've set the same rule for documentation that we
 had for unit and functional testing: a patch with no documentation or no
 unit tests or no functional tests is refused. This allowed us to build a
 complete and (almost) properly documented and fully tested project from
 scratch in less than a year. That's an idea I'd like to push further in
 other OpenStack projects.
 
 I hope and I think I'm continually striving to make OpenStack better as
 a whole and I want to push that further in all projects so that we can
 go faster to push our vision out.
 
 It seems to me that the TC had a very small power so far to influence
 the community and projects, though I hope we'll anyway be able to reach
 out to the projects in an efficient way to communicate our ideas!
 
 
 Happy hacking!
 
 
 ¹  http://launchpad.net/gnocchi
 
 
 
 __
 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
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC Candidacy

2015-04-22 Thread Tristan Cacqueray

confirmed

On 04/22/2015 03:52 AM, James E. Blair wrote:
 Hi,
 
 I'd like to announce my candidacy for re-election to the TC.
 
 About Me
 
 
 I am the PTL for the OpenStack Infrastructure Program, which I have
 been helping to build for nearly four years.  I have also served on
 the TC since the Icehouse cycle.
 
 I am responsible for a significant portion of our project
 infrastructure and developer workflow including setting up gerrit and
 helping to write git-review.  All of that is to say that I've given a
 lot of thought and action to helping scale OpenStack to the number of
 projects and developers it has today.
 
 I also wrote zuul, nodepool, and devstack-gate to make sure that we
 are able to test that the different componensts of OpenStack work
 together as a cohesive whole.  A good deal of my technical work is
 focused on achieving that and ensuring that all of the projects that
 make up OpenStack have the ability to test themselves in such a
 complex system.
 
 Throughout my time working on OpenStack I have always put the needs of
 the whole project first, above those of any individual contributor,
 organization, or program.  I also believe in the values we have
 established as a project: open source, design, development, and
 community.  To that end, I have worked hard to ensure that the project
 infrastructure is run just like an OpenStack project, using the same
 tools and processes, and I think we've succeeding in creating one of
 the most open operational project infrastructures ever.
 
 My Platform
 ===
 
 I am very excited about the big tent.  The infrastructure team has
 been involved in operating stackforge for some time, and so the big
 tent idea seems like a natural progression to me.  We have a lot of
 folks who are participating in our community and it is time that we
 accept them in.  At the same time we can strengthen the core of our
 project by acknowledging that there are a lot of components that can
 be a part of OpenStack, but not all of them need to be deployed in
 every installation.  And so the layered approach helps us make sense
 of how a system should be constructed.
 
 As part of the move into the big tent, all of the cross-project
 efforts will need to change the way they operate to accomodate the
 scale we are dealing with.  Most of that work is well underway, but
 the TC itself will need to change as well.  Just as any other
 horizontal effort, the TC will need to provide the tools and processes
 for projects to be effective members of our community on their own.
 Part of the motivation for adopting the big tent strategy is to get
 the TC out of the business of doing detailed review of projects so
 that it can provide technical leadership for OpenStack as a whole.
 
 I believe we have made a great start on the work that is needed to
 build the big tent.  There is still more work that needs to be done, I
 would like to continue to help the TC evolve into its new role and so
 I would appreciate your vote.
 
 Thanks for your consideration,
 
 Jim
 
 __
 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
 
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC Candidacy

2015-04-21 Thread Tristan Cacqueray

confirmed

On 04/21/2015 04:47 AM, Flavio Percoco wrote:
 Greetings,
 
 I'm announcing my candidacy for the Technical Comitee Elections.
 
 I wish I could say I've served as a TC member before but I haven't.
 However, there's always a first time for everything, isn't there? I'd
 like for Liberty to be that chance for me to be honored with a seat in
 OpenStack's Technical Comitee.
 
 I believe I've been part of OpenStack's community long enough to know
 how it works, the mechanisms behind it and I believe I have a good
 feeling of where it should be headed. Here are some things that I'd
 love to help achieving as part of my work as a TC member:
 
 # Paradise's doors have been opened but no maps of it have been drawn:
 
 During the last cycles, the TC members have done an amazing job on
 helping make our community more welcoming. The bar for inclusion has
 be lowered to the point where projects are welcomed to join it as long
 as they meet the minimum requirements established in our governance
 repo.
 
 I believe this is an amazing step for our community but we're not
 there yet. Unfortunately, opening our doors does not do the trick. In
 order to keep this openness honest, we also need to provide a better
 support for the projects that are joining our community.
 
 Therefore, I'd like to help moving the big tent effort forward and
 start laying down the bases that will help providing support to
 projects and guide them especially in moments where decisions like
 this[0] need to be taken.
 
 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2015-April/061967.html
 
 # Help with clearing the path where OpenStack is headed
 
 For better or for worse, one of the question I've been asked more
 often, in the last couple of months, is: Is OpenStack there yet?
 What's next?
 
 OpenStack is a cloud provider and as such it should strive to cover
 enough use-cases to make cloud consumers'/providers' lives simpler.
 There's more to a cloud than just compute, storage and networking.
 There's more to cloud than just orchestration and meetering. As part
 of my role as a TC member, I'd like to help our community grow in
 other areas that might not be considered required but that are still
 important for our mission.
 
 # Deployments / Ops
 
 OpenStack has come a long way on making deployments easier but again,
 we're not there yet. With the new governance model, we won't just see
 new *aaS services joining but also new tools[0] that are meant to help
 with OpenStack's installation and maintenance.
 
 Along the lines of what I said in my point #2, I believe having tools
 to install OpenStack is great but there's more to an OpenStack
 deployment than just that. There's monitoring, upgrades, migrations,
 etc.
 
 As part of my journey as a TC member (hopefully), I'd like to help
 these projects by exploring and gathering the needs and feedback from
 our community so we can guide these amazing efforts towards the right
 solution that OpenStack needs.
 
 I believe OpenStack is taking giant steps towards a great success but
 we need to be careful not to skip important things in between those
 steps. I'd like to use my knowledge from my involvement in several
 areas throughout OpenStack (and outside it) to help OpenStack moving
 forward at the same - or at a better - pace.
 
 Thanks for your consideration,
 Flavio
 
 P.S: If you're thinking. Wait, this guy is nuts. He ran for 2 PTL
 positions and he now wants to run for a TC position. Is he crazy? One
 answer to that could be, Yes. However, just to make sure it's clear to
 everyone my current time situation, I'd like to share that I'm
 just Zaqar's PTL - Nikhil is Glance's PTL - and my current
 commitments allow me for dedicating to this position the time it
 requires.
 
 
 
 __
 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
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC Candidacy

2015-04-21 Thread Elizabeth K. Joseph

confirmed


On Tue, Apr 21, 2015 at 5:29 PM, Jay Pipes jaypi...@gmail.com wrote:
 Hey Stackers,

 I'd like to continue serving on the Technical Committee, and I'm asking for
 your votes in the upcoming elections.

 Here's my ask of you, dear voter:

 #1.

 Please do NOT vote for me just because you may recognize my name being
 around the OpenStack community for a long time. Being a long-time member of
 something does not make me any more able to offer creative solutions to our
 problems than someone who's been in our community for a year or so.

 #2.

 Please do NOT vote for me just because I'm currently on the Technical
 Committee and have served on the TC in the past. There is no carry-over
 power that someone that has served on the TC in the past brings with them to
 bear on future TCs. Ideas and a person's ability to debate the issues fairly
 and concisely are what determines the effectiveness of a TC member, not the
 length of time they have served on the TC.

 #3.

 Please do NOT vote for me because you think I am (often unduly) outspoken or
 critical about certain particular issues that you find dear. Even if you
 hate XML as much as I do or would love to see API extensions die in a fire,
 you shouldn't vote for me just because you happen to agree with me on those
 particulars. The TC is not about squabbling and religious wars. It's about
 BIG ideas and listening to the viewpoints of others and seeing how the
 OpenStack contributor ecosystem can be shaped by those ideas in meaningful
 ways.

 #4.

 Please DO vote for me because you think I will fairly consider the
 viewpoints of the other TC members -- whomever they happen to be.

 #5.

 Please DO vote for me because you think I will be diligent in gathering the
 feedback of our disparate and excellent contributor teams, and critically,
 use that feedback to make our OpenStack community better for us all.

 #6.

 Please DO vote for me if you believe I will be an advocate for OpenStack's
 contributor community in the broader open source ecosystem, and continue to
 further the ideals of our four Opens [1].

 Thanks much,
 -jay

 [1] https://wiki.openstack.org/wiki/Open

 __
 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



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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

Re: [openstack-dev] TC candidacy

2015-04-21 Thread Elizabeth K. Joseph

confirmed


On Tue, Apr 21, 2015 at 4:02 PM, Angus Salkeld asalk...@mirantis.com wrote:
 I'd like to announce my candidacy for the Technical Committee elections.


 This last (Kilo) cycle I have been the PTL for Heat, but will not be for
 Liberty.

 Because of this, if I get elected to the TC, I can dedicate a significant
 amount of time to TC duties.

 I have an interest in projects that exist in the upper layers in OpenStack
 (Heat, Murano, Mistral, Ceilometer/Monasca, Zaqar), so this gives me a
 slightly different viewpoint than the existing TC members (I hope this will
 be complementary).


 Topics that I am interested in pursuing:


 1. How can the TC/PTL's better influence what developers work on?

 We currently have working groups and project tags, but are there other ways
 that we can encourage developers to work on global issues that users and
 operators are asking for?

 So if the TC came up with say 2 global themes every cycle, let's say ease
 of upgrades and scale, what can we use as a carrot to encourage a
 developer to work on these topics rather than something else. Clearly this
 has limits, but if the user survey is screaming we need X, it would be
 great to have a tool to help focus developers onto this.

 One idea might be to use stackalytics main page to show the work done on TC
 selected blueprints/bugs. We could tag particular blueprints/bugs and
 highlight the developers that have worked on these (i.e. can we use
 stackalytics as a tool to motivate developers to work on
 TC supported themes).

 A note on this (some motivation for taking advantage of stackalytics):
 It looks like this commit changed the default view on stackalytics from
 commits to reviews
 https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c
 (14 Apr 2014)
 http://stackalytics.com/?release=allmetric=commits
 http://stackalytics.com/?release=all

 See the sudden plateau of commits and increase in reviews after that time on
 the top graph (I am sure there are other factors at play too).


 2. How can we better support new foundational projects that we expect other
 projects to consume.

 Under the new big tent model, we are welcoming more projects into the
 openstack/ code namespace while simultaneously shifting the determination of
 production-worthiness to distributors and operators. This poses a problem
 for projects like Zaqar, Mistral, and even Heat, as these projects may be
 consumed/used by other upper-layer projects. Consuming projects end up with
 lots of conditional code as they must take into account that the deployed
 cloud may not have these dependent projects installed.

 How can we make the end user (and inter-project) experience richer and
 friendlier with a consistent method of negotiating and discovering the
 underlying features a deployed cloud offers?

 Could tenant-based services/endpoints be helpful in allowing end users to
 install optional projects?


 3. Getting notification messages to the end user.

 Based on this:
 http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html

 Other clouds provide better messaging feedback on what the infrastructure is
 doing. We are really missing this and I'd like to help to get us to the
 point where the user (that doesn't have access to the logs) can understand
 what has happened to their resources.


 I'm interested in either leading or participating in working groups from
 within the TC to address these issues.


 Thanks
 Angus Salkeld

 __
 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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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

Re: [openstack-dev] TC candidacy

2015-04-20 Thread Tristan Cacqueray

confirmed

On 04/20/2015 05:56 AM, Thierry Carrez wrote:
 Hello list,
 
 I'm announcing my candidacy for the Technical Committee elections.
 
 I have been serving as the chair of the Technical Committee since its
 inception, but I think we are at a critical point in the evolution of
 the role of the Technical Committee, and if you allow it, I'd like to be
 around to help drive us through this transition.
 
 In particular, I'd like the Technical Committee to push in 3 new
 directions during the Liberty cycle:
 
 
 1. Step out of the way
 
 As I explained on [1], I think over the last cycles the TC pushed the
 regulation and ask for permission cursor so far we actually start
 preventing things from happening. I'd like us to come back to a point
 where our community is more trusted by default, where it asks more for
 forgiveness and less for permission. So I'd like the Technical Committee
 to look into its processes and see where it can remove itself from the
 action pipeline, and retreat back to being an appeals board should a
 problem arise.
 
 [1] http://ttx.re/stepping-out-of-the-way.html
 
 
 2. Start addressing real issues
 
 I think it is part of the role of the Technical Committee members to
 detect, investigate and help solving issues in our development
 community. As we grow, we can't expect every member to know everything
 about every project in OpenStack. But each member should be able to dive
 into specific project(s) and report issues to the group. Subgroups of
 members should be able to work together on proposing plans to solve
 long-standing issues. That means spending more than one hour per week on
 TC matters, which is why I'd like us to give preference in TC elections
 to candidates who have enough time on their hands, as explained on [2].
 
 [2] http://ttx.re/tech-committee-candidates.html
 
 
 3. Push toward both ends of the scale space
 
 Taking a step back on those last 5 years, I think the natural forces
 behind OpenStack development made us cover the middle-tier of usage
 quite well: reasonably large private IaaS systems (~10k VMs) with a need
 for extra features and accepting the resulting complexity. They did not
 make us cover the hyper-scale end (public clouds with millions of VMs in
 a very active usage pattern) that well, because that end
 is a specific use case that needs specific trade-offs, and not so many
 users need/push those. And it did not make us cover the basic system
 end, where people want to deploy a base IaaS compute system without
 bells and whistles, and without a team of 100 admins, most of them SDN
 specialists.
 
 Our development ecosystem won't naturally go and cover those use cases
 (lack of business and/or market), but those are essential long-term. We
 all need extremely-large OpenStack public clouds to burst hybrid
 workloads to. And we all need people to be able to experiment with
 OpenStack in POCs, labs and universities. This is the two directions I
 want to encourage in the near future.
 
 
 More generally, I think it is the role of the Technical Committee
 members to provide a long-term vision. To influence where we are going,
 beyond where the market forces push us. To inspire our developers to
 work (or support work) to cover areas that their employer might not
 immediately care about in the short term. To make OpenStack better and
 more universal in the long run.
 
 Thanks for your consideration,
 




signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] TC Candidacy

2014-10-10 Thread Anita Kuno

confirmed

On 10/10/2014 01:52 AM, David Lyle wrote:
 I would like to announce my candidacy for the Technical Committee.
 
 I have been working on OpenStack since the beginning of the Grizzly cycle.
 I started working on OpenStack as part of HP's Public Cloud effort. I spent
 two years working to make Horizon work in that scale of environment and
 making Horizon the user facing interface of HP's Public Cloud. I have
 served as a Horizon core reviewer since the Havana cycle and I am starting
 my third release as Horizon PTL. Currently, I am employed by Intel in their
 Open Source Technology Center.
 
 I have been a regular observer of the Technical Committee during my time as
 PTL. The role of the TC is large and difficult. I appreciate the efforts of
 all those that have served during that time and I would like to thank them
 for their dedication. One takeaway from those observations in the very
 heavy representation on the TC by infrastructure and core services. I think
 the TC would be benefit from more representation higher up the stack. I
 think Heat, Horizon, Solum, TripleO have a unique perspective into
 cross-project issues and the TC would benefit from such representation.
 
 In my opinion, the fundamental problems the TC needs to address in the Kilo
 cycle are handling growth and cross-project alignment. I'll be honest, I
 don't have a master plan to address these, but I think I'm well equipped
 and motivated to help develop that plan with other members of the TC.
 
 Thanks for your consideration,
 David Lyle
 
 
 Topic: OpenStack Mission: How do you feel the technical community is doing
 in meeting the OpenStack Mission?
 
 
 To produce the ubiquitous OpenSource Cloud Computing platform that will
 meet the needs of public and private clouds regardless of size, by being
 simple to implement and massively scalable.
 
 I think this is a very broad mission. Breadth is not a problem, but there
 are a few implications in here. One OpenStack needs to be inclusive, to
 accomplish ubiquity we need to strive to allow deployers to meet their
 widely varied needs. So we need to support a large ecosystem. The ecosystem
 around OpenStack is certainly large, but there is a fairly sharp dichotomy
 between OpenStack and not OpenStack, recognizing larger parts of the
 ecosystem is important for ecosystem health. As to public vs private and
 massively scalable aspects, I think we have room for growth. Running a
 public cloud on OpenStack requires not insignificant changes, and OpenStack
 has room for improvement on the scalability front. We need greater feedback
 from the very large deployers to make sure we meet those scalability needs.
 
 Topic: Technical Committee Mission: How do you feel the technical committee
 is doing in meeting the technical committee mission?
 
 
 The Technical Committee (TC) is tasked with providing the technical
 leadership for OpenStack as a whole (all official programs, as defined
 below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
 Integration, Quality...), decides on issues affecting multiple programs,
 forms an ultimate appeals board for technical decisions, and generally has
 oversight over all the OpenStack project.
 
 The technical committee has spent much of the last cycle acting as gate
 keeper. I would like to see it take a larger role in overall architectural
 direction in OpenStack. I believe one of the greatest challenges we face is
 coherency of vision and direction. I think this should be the province of
 the technical committee to act as an arbitrar and architectural board. I
 don't hold that overall technical direction is to be dictated by the TC,
 rather the TC merely helps unify that direction and insures consistency.
 Obviously this is a herculean task, but I believe OpenStack needs more
 clearness in direction.
 
 Topic: Contributor Motivation: How would you characterize the various
 facets of contributor motivation?
 
 
 Contributors are motivated to contribute for various reasons. People
 contribute for personal interest, corporate interest, academic interest,
 and any mix of all three. Corporate interest covers a lot, from users to
 operators, vendors to consumers. Many ideas from our great community of
 diverse contributors helps drive us forward and keeps us honest and
 progressing.
 
 At the end of the day, OpenStack is cloud software that should be usable.
 We do need to temper the wouldn't it be neat if, with how will this work in
 real world application ranging from small test clouds to large public
 clouds. Services should strive

Re: [openstack-dev] TC Candidacy

2014-10-09 Thread Tristan Cacqueray

confirmed

On 09/10/14 09:07 AM, John Garbutt wrote:
 Hi,
 
 I would like to run for a seat on the Technical Committee, to help
 serve the whole OpenStack community during this time of change.
 
 I am employed by Rackspace, working on their public cloud. I am
 currently focus mostly on Nova. I am nova-core, and currently nova's
 blueprint czar. I am johnthetubaguy on IRC.
 
 I started contributing to OpenStack, working as a researcher at Citrix
 in December 2010. I helped create Citrix's Project Olympus packaging
 of OpenStack (nova, swift and glance). After a change in strategy I
 started working more on making OpenStack work with XenServer, setting
 up one of the first Nova sub groups. After my move to Rackspace in
 February 2013, I was able to work on all parts of Nova, and quickly
 got more involved with a wider range of upstream activities.
 
 I find the work of building a consensus really rewarding. I don't
 claim to have all the answers, but I know we need change, so we can
 scale out the community, while at the same time we preserving the true
 nature of this awesome community.
 
 
 ** Topic: OpenStack Mission
 ** How do you feel the technical community is doing in meeting the
 OpenStack Mission?
 
 Its a bold mission, and I think it is still the right one.
 
 serve developers, users, and the entire ecosystem
 I think we need to be better at the serving the entire ecosystem.
 
 Look at Vi vs Emacs. StachTach vs Celiometer? We are a big community,
 we should learn to embrace the diversity, where goals don't quite
 align. But we still want it to be easy for anyone to join in with any
 exiting effort people are working on. People invest in competing
 startups.
 
 On the other side of the coin, its hard for our users to know what
 combinations of drivers give you are working system, and a system that
 solves the problems the user wants to solve. Distros and consultants
 are helping fix that. But I am not sure the Vendors always know what
 they need to participate in the most useful ways.
 
 We need to better understand what interoperability means with this
 broader scope. But making it easy for people to use multiple different
 OpenStack implementations is important. Nova API should always behave
 like Nova API, Cinder API should always behave like Cinder API, etc.
 
 
 ** Topic: Technical Committee Mission
 ** How do you feel the technical committee is doing in meeting the
 technical committee mission?
 
 TC is clearly aways striving to do better, and trying out new ideas,
 which is great.
 
 Evolving the concept of the integrated release is clearly key to
 making the system scale. There seems to have been much friction over
 the incubation process.
 
 Helping share what has worked well between all the projects, seems key
 to providing technical leadership at large scale. Thats starting to
 happen, which is cool.
 
 Should the TC reduce its scope to some small number of projects? I am
 not sure. Maybe there needs to be a different group setup to deal with
 the specifics related to that group of projects? Maybe ttx's cross
 project meeting is already the beginnings of that group?
 
 
 ** Topic: Contributor Motivation
 ** How would you characterise the various facets of contributor motivation?
 
 I feel we are a community of problem solvers, and wanting to
 collaborate and make an impact.
 
 Many of us do this work as (some or all) for our full time jobs. That
 leads to people being put into a position where the problems they are
 able to work on can be constrained by their employer.
 
 We need to get better at educating those who employ people working on
 OpenStack, on how they can get the best out of their investment. For
 example, not testing things upstream, is really going to hurt.
 
 
 ** Topic: Rate of Growth
 ** There is no argument the OpenStack technical community has a
 substantial rate of growth. What are some of the consequences of this
 rate?
 
 Yes, its hurting, and it touches everything. But thats fun, and brings
 new ideas, and challenges, which keeps us evolving and adapting. We
 need to take care to unlearn things that get in the way too.
 
 
 ** Topic: New Contributor Experience
 ** How would you characterize the experience new contributors have currently?
 
 I enjoyed how I was welcomed into the OpenStack community. But it was
 scary then, and it has to be worse now. We all need to do our part to
 be open and welcoming to people.
 
 But we should probably look at who is leaving our community. I
 certainly see people step back due to frustrated with the contribution
 process. Sometimes burning out after feeling like their ideas are
 torn to shreds or feel like the are battling pointless bureaucracy.
 The solutions are hard, but it feels like getting better at
 documenting the intent of a process, would help, better setting of
 expectations around how debates will work, would help. I find rather
 than trying to merge my patch, its better to collaborate in solving
 my problem.
 
 
 **

Re: [openstack-dev] TC Candidacy

2014-10-09 Thread Anita Kuno

confirmed

On 10/10/2014 01:22 AM, John Griffith wrote:
 I'd like to announce my candidacy for the OpenStack Technical Committee
 Fall 2014 elections.
 
 I've been contributing to OpenStack for almost three years now (this months
 my anniversary) and up until this election cycle have served as PTL for the
 Cinder Project.  Over the years I've had the opportunity to be on the TC
 both as a result of PTL (back when PTL's were reserved seats) as well as by
 election.  Last spring however I chose not to run for a seat, for a number
 of reasons.  For one I didn't feel as though I had the bandwidth to really
 dedicate as much as I should but more importantly I didn't necessarily feel
 that what I was doing was really that worthwhile.
 
 Since then there's been a number of ideas proposed about changing some of
 our models including the role of the TC.  I really believe that this is
 something that we need to do and am excited about the potential
 opportunity.  I think there's a lot that needs to be done here, I also
 think it's going to be a learning experience and something that's needed is
 an open mind.
 
 After the Juno cycle I decided not to seek another term as PTL partly
 because I didn't feel that I would be able to effectively fulfill the role
 of PTL and serve as a member of the TC.  So I decided that for me, I'd like
 the opportunity (if elected) to focus on contributing more broadly to
 OpenStack with a focus on service on the Technical Committee.
 
 Answers to the candidacy questions are below.
 
 Thanks,
 John
 
 
 
 Topic: OpenStack Mission
 How do you feel the technical community is doing in meeting the OpenStack
 Mission?
 
 Just as a refresh: To produce the ubiquitous OpenSource Cloud Computing
 platform that will meet the needs of public and private clouds regardless
 of size, by being simple to implement and massively scalable.
 
 So I always find this one a bit challenging to digest to be honest.  I
 think the ubiquitous part is coming along and is becoming a reality and I
 also think that there's a decent balance between public and private clouds
 and that the relative term size could be interpreted as something that's
 being addressed fairly well thus far.
 
 Those are the good now for the not so good; simple to implement; I
 don't think deployment is  quite as bad as it's made out to be at times,
 but it certainly leaves a bit to be desired.  One thing that's always
 bothered me here is that it's always been left to the distros to provide
 their custom deployment tools and we've never been able to even provide a
 common deployment foundation as a community.  I really think that's too
 bad, you can build the greatest software project there is, but if people
 can't comprehend all the pieces let alone install and configure it fairly
 easily it's really not living up to it's potential.
 
 From the perspective of the TC, I'm really not sure what role the TC is
 playing in the overall mission to be honest.  In my opinion the TC has
 really become mostly a committee relegated to voting on project incubation
 and proposals for things like project mission statements.  It's really not
 very technical in my opinion and it's also not overly effective either.
 
 In my opinion the TC needs to undergo some changes, it would be great as
 others mentioned to move away from just voting on incubation motions and
 mission statements or gap analysis efforts and actually focus more on
 technical decisions that impact OpenStack as a whole.  For example I think
 it would be great for the TC to take a more active role in really having a
 deep understanding of how all of the various OpenStack projects are
 actually coming together, what they're doing that works, what they're doing
 that's not and perhaps provide some guidance and input as well as technical
 leadership and direction.  I'm certainly not saying they should be an all
 powerful oversight group, but I do think the focus as it stands currently
 is wrong.
 
 
 Topic: Technical Committee Mission
 How do you feel the technical committee is doing in meeting the technical
 committee mission?
 (Reading from the Mission Statement here: [2])
 
 I'm not sure that given the current state of OpenStack and the number of
 projects and proposed projects the TC can be faulted for anything here.
 The fact is that it's become a full time job to just try and keep up to
 date on all the constantly changing projects in the ecosystem, not to
 mention all the newly proposed projects.  I do think that it would be
 helpful if the TC was able to be adjusted and tweaked a bit such that it
 had a more active engagement in technical direction of the project; say for
 example driving things like making installation more of a community effort,
 providing HA options that really work and most of all pushing every project
 in OpenStack to be responsible for making the upgrade process better.  I
 also think that the TC needs to make some really hard decisions about
 things; like

Re: [openstack-dev] TC Candidacy

2014-10-08 Thread Tristan Cacqueray

confirmed

On 08/10/14 05:51 AM, Eoghan Glynn wrote:
 
 
 Folks,
 
 I would like to throw my hat into the ring for the upcoming Technical
 Committee election.
 
 I've been involved in the OpenStack community for nearly three years,
 starting off by becoming core on glance, before moving my focus mainly
 onto the ceilometer project. Along the way I've landed a smattering of
 commits across nova, heat, cinder, horizon, neutron, oslo, devstack,
 and openstack-manuals, while contributing to the stable-maint effort
 over multiple cycles.
 
 More recently, I've served the ceilometer project as PTL over the Juno
 cycle, and will be doing so again for Kilo.
 
 I'm employed by Red Hat to work primarily upstream, but I also have
 some perspective on the sausage machine that operates downstream in
 order to put the technology we produce into the hands of users.
 
 My motivation in running is to bring more perspective from a smaller
 project to the deliberations of the TC, which I think already has a
 tonne of large-project and cross-project perspective to draw on.
 Balance is a good and healthy thing :)
 
 As a community we have a big challenge ahead of us to figure out how
 we respond to the growing pains that been felt in our governance
 structure and cross-project resources. This has crystallized around
 the recent layering and big tent discussions. My own feeling has
 always been in favor of a big welcoming tent, but I'm less convinced
 that a small blessed core is necessarily a corollary of such
 inclusiveness. Before we radically alter the release cycle model
 that's served us relatively well thus far, I think a critical eye
 should be brought to the proposals; in particular we really need to
 clearly identify the core problems that these proposed changes are
 intended to solve.
 
 And so, onwards to the stock questions ...
 
 Topic: OpenStack Mission
 
 
 How do you feel the technical community is doing in meeting the
 OpenStack Mission?
 
 In all honesty, I would give us an A+ for effort, but more like a B-
 for execution. In our excitement and enthusiasm to add shiny new
 features, we sometimes take our eye off the ball in terms of what's
 needed to make the lives of our users easier. I'm as guilty of this as
 anyone else, perhaps even more so. But I think at this stage, it would
 be of much benefit to our user community if we swung the pendulum
 somewhat in the other direction, and shifted some focus onto easing
 the practical challenges of operating our stuff at scale.
 
 Topic: Technical Committee Mission
 ==
 
 How do you feel the technical committee is doing in meeting the
 technical committee mission?
 
 Well, to be honest, if I thought this couldn't be improved, I wouldn't
 be running for election.
 
 On the one hand, I felt the gap analysis for already-integrated
 projects was a good and healthy thing, and certainly assisted in
 focusing resources over Juno on the areas where the TC saw
 deficiencies.
 
 On the other hand, I was quite disheartened by how some of the TC
 discussions around project status played out. IMO there was a failure
 of due diligence and mentoring. If we continue to have the TC making
 important determinations about the future of projects (whether it be
 their integrated status or their production readiness), then I think
 we need to ensure that the TC keeps itself fully appraised from an
 earlier stage about the direction that the project is taking, and
 gives fair warning when it feels that a project needs a
 course-correction.
 
 Topic: Contributor Motivation
 =
 
 How would you characterize the various facets of contributor
 motivation?
 
 Most of my prior opensource experience was on various Apache projects
 and in contrast it's striking that the OpenStack contributor community
 is on the whole more skewed away from pure volunteerism, and towards
 corporate contributors. By that, I mean contributors who are employed
 by major operators and distributors of OpenStack, where their day-job
 is to go forth and make it better. On balance, this is actually a
 strength in our community. It certainly aids in the continuity and
 sustainability of effort. It also helps ensure that less glamorous,
 but ultra-important, efforts such as stable-maint and vulnerability
 management get the attention they deserve.
 
 However, despite this skew, I'm well aware that we're building a
 broad church here. I think we all benefit from active efforts to
 build diversity in our contributor community and harness the energy of
 contributors with all kinds of motivations. Not just because it's the
 right-on thing to do, but because it's the *smart* thing to do
 ... ensuring that we get access to all of the talents, especially from
 previously under-represented groups. Towards this end, I continue to
 support the efforts of programs such as the GNOME OPW and their recent
 moves towards extending their reach to a wider

Re: [openstack-dev] TC candidacy

2014-10-08 Thread Tristan Cacqueray

confirmed

On 07/10/14 10:06 PM, Adam Lawson wrote:
 Hello everyone!
 
 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I hate the spotlight. But the importance of
 Openstack in the cloud marketplace is increasingly important as is the
 integrity of its technical direction. So I'm going to step on a limb here
 and enter the circle.
 
 My involvement has been primarily focused on large designs and deployments
 of custom automated Openstack clouds. And while I am more than proficient
 in Python and numerous other languages including .NET/J2EE and others, my
 greatest pleasure has been architecting solutions that are powered by
 Openstack. Focusing on that has really given me a unique perspective. Not
 just on individual components and how they interact with each other, but
 also how they collectively perform within the context of a heterogenous
 hybrid cloud solution while adhering to industry best practices. This
 perspective is one that I hope to bring to the technical committee if the
 Openstack community is so inclined. Not only to shepherd how Openstack is
 put together but to help enable an easier and more seamless adoption cycle
 within the enterprise.
 
 Lastly in the spirit of full disclosure, I am the principal architect for
 an Openstack consulting company I founded which strives for an accelerated
 enterprise adoption of the open cloud through, in part, the successes of
 Openstack. So one could say I am vested in Openstack in a pretty unique way
 compared to most others. So where technical direction is concerned, I
 believe I have a deep well of experience from which to draw via designing
 and developing production Openstack clouds in the real world - day in and
 day out - which I believe would be of immense value to the TC and the
 community supporting the project itself.
 
 I know there are some really smart people who want to also serve on the TC
 with focuses on various areas of Openstack and thankfully the committee was
 designed to accommodate multiple unique perspectives for that very reason.
 My hope is that the community chooses to include my program-agnostic
 architectural influence to the TC while maintaining the same work ethic and
 unyielding commitment to efforts that will deliver excellence to and within
 the Openstack platform.
 
 So without any further adieu, below are my thoughts re the requested
 questions and thanks for your consideration!
 
 *My name is Adam Lawson, running for election to the Openstack Technical
 Committee, and I approve this message.* ; )
 
 *Topic: OpenStack Mission*
 *How do you feel the technical community is doing in meeting the OpenStack
 Mission?*
 
 *“To produce the ubiquitous Open Source Cloud Computing platform that will
 meet the needs of public and private clouds regardless of size, by being
 simple to implement and massively scalable.”*
 
 The whole point of mission statements is merely to identify what we are
 striving to achieve or accomplish within the organization. With that said,
 I feel that technical leadership is the first step to accomplishing a
 technical goal. So to that end, the existence of the TC is a positive first
 step. But it's just one step or many more to come.
  Within this particular TC cycle, I'd like to see the TC demonstrate
 leadership to drive a reduction of lingering technical debt and address API
 and module standardization. Openstack in its current form has a number of
 challenges that are affecting our ability to scale and while some of this
 can be solved organizationally, technical debt and standardization are
 challenges that will not be easy to resolve and might not even be 100
 percent solvable within a single release cycle. But I look forward to how
 the TC *will* shepherd improvements to both process and the product and
 help drive the mission.
  On a side note, easy to implement is still just a goal and the
 engineering requirement to deploy and manage Openstack is still a
 prohibitive hurdle for many organizations. But we have more than one tool
 in front of us that will help us to help others who want to use Openstack
 but .. can't. That's something I'd really like to see change soon.
 
 *Topic: Contributor Motivation*
 *How would you characterize the various facets of contributor motivation?*
  I like what I read earlier today: People want to do work that matters and
 enjoy doing it. This sums up Openstack contributors very well but it sums
 up

Re: [openstack-dev] TC candidacy

2014-10-08 Thread Adam Lawson

It seems I left out a response. Sorry for the follow-on but here's what was
missing.

*Topic: Technical Committee Mission*
*How do you feel the technical committee is doing in meeting the technical
committee mission?*

*The Technical Committee (TC) is tasked with providing the technical
leadership for OpenStack as a whole (all official programs, as defined
below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
Integration, Quality...), decides on issues affecting multiple programs,
forms an ultimate appeals board for technical decisions, and generally has
oversight over all the OpenStack project.*

I believe the TC has thus far done a pretty fair job given the team and its
charter are both rather new. While the TC has been providing leadership for
individual components, I would not characterize the TC today as providing
highly visible leadership (necessary for openness and transparency) which I
would like to see improved. Much of the TC's work today coalesces around
providing a safe harbor for meaningful program integration and ensure
challenges are resolved optimally but the TC needs to get better at
identifying the good/poorly-defined boundaries of this kind of technical
governance model. In other words, the TC needs to get better at being a
good TC. The instantiation of a TC is a perfect first step but the pink
elephant in the room seems to be around cross-project and architectural
guidance; ensuring Openstack as a whole is moving in a direction that
doesn't require accommodating things we shouldn't be doing in the first
place. The lack of API standardization is a great example of moving in a
direction without a big picture context.
 Communications that have gone back and forth and debated about the big
tent model, layers/cascading, scaling documentation, etc have been visible
and the candor of opposing viewpoints have been awesome to follow. But we
could really benefit from some structural adjustments so more decisions
placed before the team are equally visible, a visible and transparent
decision-making process enabling those who use Openstack understand the
architectural perspectives shepherding it. Not just the decision that have
100+ replies on the mailing list
 Oversight over all the projects is an area that I'm anticipating where
we have some easy low-hanging fruit. Where we are today with regard to
focus is understandable given the number of fires affecting individual
programs that cannot be ignored. But we have a big opportunity (there's
that word again) to get some traction on the larger architectural decisions
that may require more work up front but produce some big wins over the long
term. Customers who want to use Openstack have often played the constant
change = unstable card for good reason; Openstack has a long way to go
before it gets to Production-quality for the masses (i.e. without heavy
re-development requirements). I believe the TC can and should influence
that with better solution-level leadership.
 - The deployment challenge is beyond ready for attention.
- A working default 'out-of-the-box' config that can boot an instance
accessible over the network is STILL a challenge. Long past due in my mind.
- Programs like Oslo that address library requirements moves a cloud closer
to Production-capable but really shouldn't be optional. Doing something
well shouldn't be optional. In fact, a Production context shouldn't be one
option of many despite the prevalence of Openstack PoC and pilots; it
should be a consistent design assumption. Gating a feature to the point
that it's 'good enough' is part of the problem. It must be
Production-worthy otherwise it is NOT good enough. That's ready for
attention.
 We might not be able to address all of these and some ideas could use a
lot more cross-talk, but if elected I would like to champion improving how
the TC approaches problems and vets their potential solutions.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson alaw...@aqorn.com wrote:

 Hello everyone!

 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I hate the spotlight. But the importance of
 Openstack in the cloud marketplace is increasingly important as is the
 integrity of its technical direction. So I'm going to step on a

Re: [openstack-dev] TC candidacy

2014-10-08 Thread Anita Kuno

On 10/08/2014 05:29 PM, Adam Lawson wrote:
 It seems I left out a response. Sorry for the follow-on but here's what was
 missing.
 
 *Topic: Technical Committee Mission*
 *How do you feel the technical committee is doing in meeting the technical
 committee mission?*
 
 *The Technical Committee (TC) is tasked with providing the technical
 leadership for OpenStack as a whole (all official programs, as defined
 below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
 Integration, Quality...), decides on issues affecting multiple programs,
 forms an ultimate appeals board for technical decisions, and generally has
 oversight over all the OpenStack project.*
 
 I believe the TC has thus far done a pretty fair job given the team and its
 charter are both rather new. While the TC has been providing leadership for
 individual components, I would not characterize the TC today as providing
 highly visible leadership (necessary for openness and transparency) which I
 would like to see improved. Much of the TC's work today coalesces around
 providing a safe harbor for meaningful program integration and ensure
 challenges are resolved optimally but the TC needs to get better at
 identifying the good/poorly-defined boundaries of this kind of technical
 governance model. In other words, the TC needs to get better at being a
 good TC. The instantiation of a TC is a perfect first step but the pink
 elephant in the room seems to be around cross-project and architectural
 guidance; ensuring Openstack as a whole is moving in a direction that
 doesn't require accommodating things we shouldn't be doing in the first
 place. The lack of API standardization is a great example of moving in a
 direction without a big picture context.
  Communications that have gone back and forth and debated about the big
 tent model, layers/cascading, scaling documentation, etc have been visible
 and the candor of opposing viewpoints have been awesome to follow. But we
 could really benefit from some structural adjustments so more decisions
 placed before the team are equally visible, a visible and transparent
 decision-making process enabling those who use Openstack understand the
 architectural perspectives shepherding it. Not just the decision that have
 100+ replies on the mailing list
  Oversight over all the projects is an area that I'm anticipating where
 we have some easy low-hanging fruit. Where we are today with regard to
 focus is understandable given the number of fires affecting individual
 programs that cannot be ignored. But we have a big opportunity (there's
 that word again) to get some traction on the larger architectural decisions
 that may require more work up front but produce some big wins over the long
 term. Customers who want to use Openstack have often played the constant
 change = unstable card for good reason; Openstack has a long way to go
 before it gets to Production-quality for the masses (i.e. without heavy
 re-development requirements). I believe the TC can and should influence
 that with better solution-level leadership.
  - The deployment challenge is beyond ready for attention.
 - A working default 'out-of-the-box' config that can boot an instance
 accessible over the network is STILL a challenge. Long past due in my mind.
 - Programs like Oslo that address library requirements moves a cloud closer
 to Production-capable but really shouldn't be optional. Doing something
 well shouldn't be optional. In fact, a Production context shouldn't be one
 option of many despite the prevalence of Openstack PoC and pilots; it
 should be a consistent design assumption. Gating a feature to the point
 that it's 'good enough' is part of the problem. It must be
 Production-worthy otherwise it is NOT good enough. That's ready for
 attention.
  We might not be able to address all of these and some ideas could use a
 lot more cross-talk, but if elected I would like to champion improving how
 the TC approaches problems and vets their potential solutions.
 
 
 *Adam Lawson*
 
 AQORN, Inc.
 427 North Tatnall Street
 Ste. 58461
 Wilmington, Delaware 19801-2230
 Toll-free: (844) 4-AQORN-NOW ext. 101
 International: +1 302-387-4660
 Direct: +1 916-246-2072

Thanks Adam, I will add this to the wikipage.

Thanks,
Anita.
 
 On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson alaw...@aqorn.com wrote:
 
 Hello everyone!

 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 09:19 AM, Anne Gentle wrote:
 I'm Anne Gentle (hi, Anne!) and I'm writing to announce my candidacy for
 the technical committee.
 
 I've served on the technical committee for two years and have been working
 on OpenStack since September 2010. I'm currently the Documentation PTL. I'd
 be honored to continue to represent the cross-project needs as well as the
 needs of the users, operators, and admins who keep an OpenStack cloud
 running every day. I've responded to the questions below so you can get to
 know me a little better. You can also see my review comments on the
 governance repo
 https://review.openstack.org/#/q/reviewer:self+project:openstack/governance,n,z
 
 Please feel free to ask me questions and challenge my assumptions. I
 believe good leaders can take on the tough work and we all know there is
 plenty of hard work to go around.
 Thanks,
 Anne
 
 Topic: OpenStack Mission
 How do you feel the technical community is doing in meeting the OpenStack
 Mission?
 The technical community consists of a huge blend of people now, thank
 goodness, because the mission is a grand sweeping one for private and
 public clouds. Plus it has the word ubiquitous in it which makes it even
 more wide-reaching. We're making clouds for the planet and I feel we're
 tackling, blocking, clearing, and fighting hard to meet the Mission. We're
 struggling with the simple to implement but we have come a very long way.
 
 Topic: Technical Committee Mission
 How do you feel the technical committee is doing in meeting the technical
 committee mission?
 I feel the TC is supportive of the technical contributors to all the
 projects that make up OpenStack. We're constantly seeking ways to improve
 and challenge programs. We began to hold programs accountable for their
 integration. We pushed the limits of the definition of OpenStack by
 defining all code that a project maintains as part of OpenStack (defined
 sections). Yes, it was a defense on the side of our Active Technical
 Contributor community base, but it was a statement about our ideals -
 Openness, Transparency, Commonality, Integration, Quality.
 
 Topic: Contributor Motivation
 How would you characterize the various facets of contributor motivation?
 Contributors are motivated in different ways, but we're all humans and
 behave like humans do. In Peter Kollock's study of online communities, he
 found these motivating factors for participating: reciprocity, reputation,
 sense of belonging, efficacy, and need. All of these make sense to me when
 put in the docs context, why would anyone contribute to upstream
 documentation? and I can also draw maps and correlations to the overall
 reasons why contributors work on upstream. We need to be aware of what
 happens when the need stems from corporate motivation, but I know that
 OpenStack is a great community to work within and that I can do my part to
 demonstrate which motivations I want to encourage in our community.
 
 Topic: Rate of Growth
 There is no argument the OpenStack technical community has a substantial
 rate of growth. What are some of the consequences of this rate?
 Hopefully by now you've seen me represent the cross-project ramifications
 of this growth rate over the years I've served on the TC. The docs program
 has had to adjust the expectations and educate incoming programs about how
 OpenStack documentation is not just project-by-project but an umbrella
 effort. People come to docs.openstack.org for OpenStack docs, not just nova
 or glance docs. I hope I have shown bravery in the face of the rate of
 growth and also pragmatism.
 
 Topic: New Contributor Experience
 How would you characterize the experience new contributors have currently?
 As an admin for the GNOME Outreach Program for Women for the last two
 years, I have helped with on-boarding new interns who have to have a patch
 in order to complete their application. Really, though, the previous
 interns do a lion's share of the work in on-boarding newcomers to our
 community. I think this is because their eyes are freshest to the
 difficulties you'll encounter while figuring out our unique processes. I'm
 also amazed at how a wonderful small community has grown up out of helping
 others learn, and that's been the best part about seeing new contributors
 coming in. We've done a lot to make installing git review easier and
 specifically setting up the gerrit remote. So the very first on-boarding
 experiences can get better. Now, the experience of those of us a few years
 in isn't great either as reviews are harder and harder to get through and
 our gate is stuffed full with patches wanting in. I think we can work on
 both experiences at the same time to make it better for all contributors.
 
 Topic: Communication
 How would you describe our current state of communication in the OpenStack
 community?
 Communication with such a wide, growing population can be difficult but I
 think we have the channels available with opt-in

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 11:25 AM, Monty Taylor wrote:
 Hi everybody!
 
 I'd like to announce my candidacy for re-election to the TC.
 
 tl;dr - Vote for me or vote for someone else you prefer
 
 I've been around the project for quite a while, having been on the phone
 calls where we were discussing the name OpenStack - although I'll admit
 I had absolutely zero decision making power there. The first decision in
 the project I took any active part in shaping was the decision to keep
 the code names nova and swift and not to rename each project
 openstack-compute and openstack-object-storage.
 
 My main technical focus within OpenStack is in Infra, where I am a
 former PTL and current core. I tend to focus energy on cross-project
 concerns over individual project concerns. I believe that a strong
 OpenStack comes from a high degree of coordination and standardization -
 but I think it's important to keep standardization in perspective as a
 tool to help us make a better product and not an goal in and of itself.
 
 As an Infra team member, I am a fairly large end-user of OpenStack.
 Infra runs across two public clouds and a private cloud run by the
 TripleO team. Although I sometimes express it in a non-productive and
 rage-filled way, I regularly experience first hand what our end users
 experience ... which is both awesome and not-awesome ... and I've been
 spending more and more of my effort on improving that experience.
 
 As may be clear from my big-tent blog post, I believe it's highly
 important to be inclusive in who we are, while at the same time
 collectively taking a higher amount of accountability for the quality of
 what we produce.
 
 Finally, there is a natural tug between exciting new features to make
 people's lives better and the quality of the existing features we have.
 We've been growing at a rather unprecedented pace over the last four
 years, so at the moment I think we need a double-down on quality and
 stability with less of a focus on adding features. As with everything
 else though, this is a balancing act and the relative importance changes
 continually.
 
 Balancing the competing needs such as the ones above is what I believe
 the main job of the TC is. We have process, we have policy, we have
 governance structure - but ultimately humans need to talk and make
 decisions, even if the decision is to do nothing. I think as the TC we
 need to own that responsibility and not shrink from it when it's hard or
 potentially unpopular.
 
 == The questions ==
 
 Topic: OpenStack Mission
 How do you feel the technical community is doing in meeting the
 OpenStack Mission?
 
 In case you haven't read it recently:
 
 to produce the ubiquitous Open Source Cloud Computing platform that
 will meet the needs of public and private clouds regardless of size, by
 being simple to implement and massively scalable.
 
 If there is anyone out there who feels we've nailed simple to
 implement I'd love to meet them. I think we've been focusing on all of
 the other parts - I'd like to see more attention placed on simple to
 implement
 
 Topic: Technical Committee Mission
 How do you feel the technical committee is doing in meeting the
 technical committee mission?
 
 In case you haven't read it recently:
 
 The Technical Committee (TC) is tasked with providing the technical
 leadership for OpenStack as a whole (all official programs, as defined
 below). It enforces OpenStack ideals (Openness, Transparency,
 Commonality, Integration, Quality...), decides on issues affecting
 multiple programs, forms an ultimate appeals board for technical
 decisions, and generally has oversight over all the OpenStack project.
 
 I think over the last year since we became all-elected, the TC has been
 doing a better and better job. Historically the TC has been a bit
 reluctant to own the words technical leadership Over the past cycle or
 two, the TC has consistently been stepping more up to the plate on this
 topic, and I think that trend needs to continue.
 
 Topic: Contributor Motivation
 How would you characterize the various facets of contributor motivation?
 
 I'm pretty sure the majority of our contributors are doing so as part of
 their jobs. I think this makes our dynamic a bit different than a
 traditional Open Source project.
 
 That said - I think we see a very strong set of people who are
 passionate about what we're doing evidenced by the number of people who
 have worked for multiple companies while working on OpenStack.
 
 I can't speak to everyone's motivation - but I can tell you what mine is.
 
 Cloud is taking over as the way we think about how IT works. It's not an
 if, it's a when. But even with that, Cloud is an idea more than a
 destination. When we started, there was one legitimate definition for
 Cloud and it was Amazon. Amazon is a closed-source company run by a
 ruthless dictator. I do not want to live in a world where I need his
 permission to use a computer.
 
 Over the last four years, we've made

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 12:47 PM, Zane Bitter wrote:
 Greetings OpenStackers,
 I would like to announce my candidacy for the OpenStack Technical
 Committee.
 
 I have worked closely with the TC since around the time that Heat was
 incubated, two years ago. I have been a regular participant in TC
 meetings throughout the Juno cycle as the Heat PTL, so I am familiar
 with the current structures and procedures, their back-story, and the
 issues that are before the committee.
 
 I think I can best contribute by digging deep into issues, rooting out
 the points of contention or misunderstanding and building consensus from
 there. If you follow openstack-dev closely you'll probably have seen me
 doing that quite a bit already. I don't claim to have all the answers,
 but I'm pretty good at asking questions.
 
 The OpenStack project has been incredibly successful in building a
 strong community where people want to collaborate on solving problems
 for our common users.[1] We are at a point where we need to readjust the
 structure of the project to better respond to the next phase of that
 success. This is not the first time we have reached such a point; nor
 will it be the last. There is no final form of the OpenStack project; we
 must approach it as we would any engineering problem (_not_, I hasten to
 add, a technical problem): by considering our goals and opportunities,
 making incremental changes, evaluating their effects (both intended and
 unintended), and repeating.
 
 I believe we need to work to reduce entropy in the OpenStack system -
 encouraging shared components and implementations over repeatedly
 reinventing the wheel - without crushing innovation. Those two goals are
 in tension (note that the wheel has been repeatedly reinvented
 throughout history, often to great effect), but they are the ones I will
 be trying to balance. And we must, of course, do this while giving
 operators and end-users confidence in their investments in the OpenStack
 ecosystem.
 
 I think making it easier for projects to join the OpenStack community
 would be a good thing, provided that still entails a commitment to doing
 things the OpenStack way backed up by meaningful oversight by the TC.
 I'm comfortable for now with leaving a high bar for graduation in place,
 though it needs to move around less. While I am in favour of more
 projects in principle, I'll be scrutinising specific projects carefully
 to make sure that they've either been able to apply the feedback part of
 the engineering process I described above with real users, or
 alternatively have solved the simplest possible version of their design
 problem with a view to maximising their flexibility to respond when they
 do get that feedback.[2]
 
 What we're really missing are stepping stones from the lower incubation
 bar to the high graduation bar. We need to do more to help projects
 understand how they can fit in to the bigger picture and what they need
 to do to get there.
 
 That will require greater involvement from the TC, but it appears we
 have already reached the point where the TC itself does not scale. That
 was evident from the Zaqar's second graduation review. One year after
 its incubation, the TC was still debating whether an SQS-like cloud
 messaging service was most comparable to AMQP, XMPP or SMTP[3] (hint:
 none of them[4]), and in the end deferred for another six months to
 figure it out. It's clear that TC members don't have the time to dig
 deeply into all the issues that cross their desks. I already proposed a
 structure whereby subcommittees in each general subject area, comprising
 a representative from each of the relevant projects plus one TC member,
 would do the investigation and mentoring of new projects and report the
 results to the TC.[5] In this model the TC would be responsible for
 setting an overall vision for the project and ensuring that it is
 applied consistently. I would welcome other proposals that could help to
 expand and deepen support for new projects in a way that can scale
 through our next stage of growth. (I am also a strong supporter of
 having formal liaison programs to boost the impact of horizontal,
 cross-project functions without stretching them to breaking point.[1])
 
 As we're figuring out structural changes I think we need to be careful
 to decouple short-term technical issues, like how to scale the gate to a
 larger number of projects that don't all have mutual dependencies, from
 longer-term structural issues. We also need to be very aware of how
 changes we make might be perceived by external parties not sharing the
 same context, including the Foundation Board and especially the DefCore
 subcommittee. Finally, we need to remember that our users see the cloud
 from many different perspectives and that no single perspective can
 capture what is important to our community.[5]
 
 Answers to the TC Election questions are below. I'm happy to answer any
 other questions folks have too, in an open forum

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 02:26 PM, Dean Troyer wrote:
 I am Dean Troyer here to nominate myself as a candidate for the upcoming
 Technical Committee election.
 
 I have been involved with OpenStack for a long time, working on the
 implementation at NASA of what became Nova. Since then I have been heavily
 involved in a number of projects: I was an early contributor to DevStack
 and served as its PTL during its short tenure as a stand-alone program, and
 started Grenade to use DevStack as the basis for upgrade testing. I also
 started the OpenStackClient project to address the disparity in user
 interface experience in our CLI tools and have been working down the client
 stack to improve the application developer experience using the client
 libraries. I currently work for Nebula Inc. from my home in the hotbed of
 overachiever baseball, Kansas City MO.
 
 Recently some ideas I wrote down regarding the technical relationship of
 OpenStack projects escaped into the wild and became part of the current
 re-thinking of what OpenStack should look like. I think these ideas are a
 result from a practical approach to building useful systems and identifying
 the natural characteristics of both the projects and the people driving
 them. Technical relationships might not define organizational
 relationships, but they often look similar in the end.
 
 The major changes being discussed are required as a result of the
 tremendous growth of OpenStack and the changes in incentives for
 contribution. This growth also feeds a desire to be all things to all
 participants that simply is not possible at this scale. We can not rewind
 the clock to the simpler times of 5 projects, but we can recover some of
 the characteristics of those days by growing through division into a larger
 number of smaller tents.
 
 I'll be happy to answer specific questions beyond the ones below…
 
 Topic: OpenStack Mission
 How do you feel the technical community is doing in meeting the OpenStack
 Mission?
 I think the rapid growth in the number of incubated/integrated projects has
 diluted the TC focus and attention and it has become clear that ignoring
 the natural strata of OpenStack projects is not working.
 
 Topic: Technical Committee Mission
 How do you feel the technical committee is doing in meeting the technical
 committee mission?
 I think this and the previous question are intertwined at this point and it
 is time to do a sanity check on where we are and where we want to go. This
 conversation has started and there is no clear answer yet.
 
 Topic: Contributor Motivation
 How would you characterize the various facets of contributor motivation?
 I think at a high level this is one of the motivations to re-evaluate our
 existing structure. We are a corporate-driven project and in spite of
 individual efforts to remain independent the corporate influence is being
 felt in ways that the individuals may have not anticipated, ie, being
 'Integrated' is the most valuable attribute for a project, and is the
 indicator for investment for many corporate managers.
 
 At an individual level I see people who want to make a better cloud and
 make the tools and components to get us there. We have some procedural
 things to smooth out (CLA, etc) and some significant scaling issues to
 address (review backlogs) in order to retain and utilize the energy being
 brought to OpenStack by new contributors.
 
 Topic: Rate of Growth
 There is no argument the OpenStack technical community has a substantial
 rate of growth. What are some of the consequences of this rate?
 As I wrote above, we have lost focus as we have attempted to widen the
 scope of integrated projects. Rather than do a smaller number of things
 very well the pressure is to do a lot of things.
 
 Topic: New Contributor Experience
 How would you characterize the experience new contributors have currently?
 The mechanics of contributing (CLA, accounts, etc) could be much better. I
 am not convinced that the CLA is providing value. The percentage of initial
 contributions that I see that are more than trivial spelling fixes or
 similar is low, as they need to focus on the process rather than the
 content just to get going.
 
 Topic: Communication
 How would you describe our current state of communication in the OpenStack
 community?
 There are enough different communication channels available that it is hard
 for anyone to monitor them all and still have time to write. I do think in
 general we have done a good job of herding conversations toward the mailing
 lists and logged IRC channels. Twitter and personal blogs are other common
 avenues and may or may not be easy to discover if one doesn't already know
 about them.
 
 Topic: Relationship with the Foundation Board
 The technical committee interacts with the foundation board on several
 different fronts. How would you describe these interactions?
 I have mostly seen the interaction around the DefCore work and have found
 it interesting that

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 04:21 PM, Russell Bryant wrote:
 Hello, everyone!
 
 I would like to run for re-election on the Technical Committee. I have
 been an elected member of the TC since it was created in the Fall of
 2012 [1]. I have been contributing to OpenStack since late 2011 (commits
 [2] reviews [3]). My most substantial contributions have been to Nova,
 where I also served as the PTL for the Havana and Icehouse releases. For
 further details on my background, see openhub [4] or linkedin [5].
 
 I have been a proactive member of the TC.  I take my broad experience
 with the project and work to turn it into change that puts us in a
 better position for the future.  Some specific examples of actions I’ve
 taken may help demonstrate this.
 
 Over the last cycle it became clear that the TC could do a better job at
 communicating what we’re up to to the broader community.  I helped
 launch an ongoing effort to blog about TC activities.  I wrote the first
 [9] and third [10] posts of this series. We now intend to rotate the
 authorship of these posts through a group of willing TC members.
 
 I’ve become deeply familiar with the history of Neutron vs. nova-network
 through my work with the Nova project.  During my second term as the
 Nova PTL, we unfortunately reached a point where we had to unfreeze
 development on nova-network [11].  I wanted to find ways to help improve
 the current situation and help prevent it from happening again.  I
 identified policy that could be added (must have explicit deprecation
 and migration plan in place before graduation) [12] for the future.  To
 help with the current situation, I proposed that we kick off a round of
 project reviews where we review all existing projects against our
 incubation and graduation requirements [13].  This process resulted in a
 gap analysis and plans for filling those gaps for Neutron [14], Trove,
 Ceilometer, Horizon, Glance, and Heat.  We are now much closer to being
 able to deprecate nova-network than we were 6 months ago thanks to some
 very hard work by the Neutron team.  I think these reviews were very
 productive and I hope to help continue this process with the TC going
 forward.
 
 The TC has the critical role to evolve and scale our structure and
 processes to ensure the ongoing health of our development community.
 We’ve worked through important changes in every cycle so far.  From
 recent discussions it is quite clear that it is time for another round
 of big changes to how we organize our teams and projects. The TC itself
 has even become a bottleneck in some cases.  I see resolving these
 issues as a top priority for the TC over the next release cycle.
 
 There are far too many things wrapped up in the incubation and
 integration statuses.  They communicate different things to different
 audiences.  This overload has led to a lot of conflict.  It’s a high
 priority for me to ensure that with whatever changes we make, we value
 an inclusive community that lets projects doing good work be a part of
 OpenStack.  We need to rework the organization such that what we’re
 communicating is the most useful information for each audience.  At the
 same time, we need allow this growth in such a way that it doesn’t
 provide unbearable strain on horizontal project resources like
 documentation, infrastructure, or release management.  The incubated and
 integrated statuses are not doing the job, but I’m confident that we can
 work through our next evolution, and I would like to be a part of
 ensuring that happens.
 
 Thank you all for your consideration. It’s an honor and a pleasure to
 work with you. If there’s anything you would like to discuss, please
 feel free to reach out to me.
 
 
 Below you will find my answers to the provided questions [6].
 
 *** Topic: OpenStack Mission
 
 How do you feel the technical community is doing in meeting the
 OpenStack Mission?
 
 To recap, the mission statement is “to produce the ubiquitous Open
 Source Cloud Computing platform that will meet the needs of public and
 private clouds regardless of size, by being simple to implement and
 massively scalable.”
 
 “ubiquitous” - I think the part we’re doing great here.  OpenStack is
 growing like crazy and is being used all over the place.  The list of
 supporting companies [7] is impressive.  The number and diversity of our
 contributors is even more impressive.  With that said, we shouldn’t get
 comfortable.  There is a lot more to go.
 
 “public and private clouds” - I think we do a nice job working to
 support both of these use cases.
 
 “regardless of size”, “massively scalable” - This one probably depends
 on who you ask.  :-)  Our scalability depends on the project.  In some
 areas we’re doing great.  In all areas, we have more improvements to
 make.  I think our biggest failure here has been how well we communicate
 what to expect to the rest of the community.  Some people expect that
 they can take every component of the integrated release to large

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 04:30 PM, Doug Hellmann wrote:
 I am announcing my candidacy for a position on the OpenStack Technical
 Committee.
 
 I am currently employed by HP to work upstream on OpenStack. I started
 contributing in 2012, not long after joining DreamHost. I am one of
 the founding members of the Ceilometer project, and a core reviewer
 for the requirements and unified command line interface projects. I am
 also part of the team working on the Python 3 transition, and have
 contributed to several of the infrastructure projects. Kilo will be my
 third term serving as PTL for the Oslo project, and I have served on
 the Technical Committee for the last year. In addition to my technical
 contributions, I helped to found and still help to organize the
 OpenStack meetup group in Atlanta, Georgia.
 
 I've included the answers to the formally posed election questions
 below, but please follow up here with any other questions you might
 have for me.
 
 The OpenStack community is the most exciting and welcoming group I
 have interacted with in more than 20 years of contributing to open
 source projects. I'm looking forward to continuing to being a part
 of the community and serving the project.
 
 Thank you,
 Doug
 
 Review history: https://review.openstack.org/#/q/reviewer:2472,n,z
 Commit history: https://review.openstack.org/#/q/owner:2472,n,z
 Stackalytics: http://stackalytics.com/?user_id=doug-hellmann
 Foundation: http://www.openstack.org/community/members/profile/359
 OpenHUB: https://www.openhub.net/accounts/doughellmann
 Freenode: dhellmann
 Website: http://doughellmann.com
 
 
 
 * Topic: OpenStack Mission
 *
 * How do you feel the technical community is doing in meeting the
 * OpenStack Mission?
 
 I am amazed by what our community produces. We have some truly
 exceptional development teams building great software. We regularly
 add new components to the system, and our feature set is as diverse as
 the community. Our work is not perfect, but as we continue to refine
 it based on experience and input from users, we are continually
 improving the way we work and what we produce.
 
 However, there are recurring themes in the user feedback after every
 release: We need to make OpenStack easier to operate, easier to use,
 and easier to debug. We are starting to build cross-project teams to
 work more directly on some of these areas, and it's important that we
 give priority to that work and consider usability and scalability as
 features.
 
 * Topic: Technical Committee Mission
 *
 * How do you feel the technical committee is doing in meeting the
 * technical committee mission?
 
 We're fulfilling most of the mission, but we can do better.
 
 The Zaqar graduation discussion is a good example of an area where we
 need to rethink how we bring new project teams into OpenStack. There
 are several similar suggestions to drop our current incubation and
 integration process completely, and that is one option. Another is to
 set up the resources we would need to do an objective technical
 evaluation for projects. I favor a combination of those two ideas,
 evaluating projects on several criteria from the users' perspective,
 but deciding the official status of a team based on community
 considerations.
 
 We have also recognized that we need some way to handle cross-project
 initiatives such as improving our logging to make debugging easier,
 but we do not yet have a formal structure in place to accomplish those
 goals. The way we set up working groups for those sorts of jobs is
 going to depend on the outcome of the bigger governance discussion,
 but I think they should be organized by the TC.
 
 * Topic: Contributor Motivation
 *
 * How would you characterize the various facets of contributor
 * motivation?
 
 I don't know if we have numbers, but my impression is that most of our
 contributions come from people employed at least in part to work on
 OpenStack. Their commitment to the project as a whole, outside of
 their area of specialty, varies for a lot of reasons. We want everyone
 to have a strong commitment to the whole project, but that's not
 always realistic, because it's not always up to the individual to
 decide how much time or effort they can put into working on OpenStack,
 or into a given area. That's perfectly normal and OK. We can, and do,
 welcome contributions from all sorts of people for all sorts of
 reasons.
 
 * Topic: Rate of Growth
 *
 * There is no argument the OpenStack technical community has a
 * substantial rate of growth. What are some of the consequences of
 * this rate?
 
 Growing so quickly is forcing us to think about how we organize our
 selves and make changes explicitly, and more rapidly, rather than
 allowing for a slower evolution.  We've had a lot of blog posts and
 mailing list threads talking about ways to handle the growth through
 governance model changes to the project. These are important decisions
 for us to make as a community, and we need to weigh both

Re: [openstack-dev] TC candidacy

2014-04-17 Thread Tristan Cacqueray

confirmed

On 04/17/2014 06:51 AM, John Dickinson wrote:
 I'd like to announce my Technical Committee candidacy.
 
 I've been involved with OpenStack since it began. I'm one of the original 
 authors of Swift, and I have been serving as PTL since the position was 
 established. I'm employed by SwiftStack, a company building management and 
 integration tools for Swift clusters.
 
 OpenStack is a large (and growing) set of projects, unified under a common 
 open governance model. The important part about OpenStack is not the pieces 
 that make up the stack; it's the concept of open. We, as OpenStack 
 collectively, are a set of cooperating projects striving for excellence on 
 our own, but stronger when put together.
 
 As OpenStack moves forward, I believe the most important challenges the TC 
 faces are:
 
 - Ensuring high-quality, functioning, scalable code is delivered to users.
 - Working with the Board of Directors to establish conditions around 
 OpenStack trademark usage.
 - Ensuring the long-term success of OpenStack by lowering code contribution 
 barriers, incorporating feedback from non-developers, and promoting OpenStack 
 to new users.
 
 As a member of the TC, I will work to ensure these challenges are addressed. 
 I appreciate your vote for me in the TC election.
 
 --John
 
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




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

Re: [openstack-dev] TC Candidacy

2014-04-17 Thread Anita Kuno

confirmed

On 04/17/2014 02:48 PM, Devananda van der Veen wrote:
 I would like to announce my candidacy for the Technical Committee this
 term.
 
 
 Background
 =
 
 I began working on OpenStack more than two years ago. Initially, I focused
 on improving Nova's database API and led the Nova DB team in that cleanup
 effort for a time. As much of that work was finished or transitioned to
 other capable hands, I began worked on the Nova baremetal driver and
 helped to start the TripleO project. At the Havana summit, I proposed that
 this driver be split into its own project, and for the last year I have
 served as the PTL for Ironic.
 
 
 Platform
 ==
 
 OpenStack is not merely a collection of open source software that,
 together, provides a cloud; it is the open community which creates and
 supports that software. While being open and encouraging new contributions,
 that developer community, led by the TC and the PTLs, has a responsibility
 to ensure the quality of the resulting software. OpenStack must be
 scalable, maintainable, and easy to install, and I believe it must also
 look and feel cohesive to operators and end-users, even if, under the hood,
 it is a collection of loosely coupled parts. Diversity in projects is good,
 as is a healthy PaaS ecosystem, but divergence away from common operational
 tooling makes it more difficult for both contributors and operators.
 
 Over the last 6 months, the TC has codified integration and testing
 requirements, both raising the bar for new projects and making the path to
 integration clearer. Some integrated projects do not meet those standards
 yet, and work is underway to remedy that. I would like to see this
 continue, leading towards greater consistency across all integrated
 projects.
 
 I believe that the greatest barrier to entry for our users is the
 complexity of installing an OpenStack cloud; addressing this is the primary
 reason that I'm working on Ironic and TripleO. Similarly, I believe the
 greatest barrier to entry for new projects is integration with the
 community of existing projects, and given my role as PTL for Ironic, I
 believe that I bring a unique perspective to this discussion. In this
 cycle, I would like the TC to be more involved in individual projects'
 technical considerations than it historically had been, particularly during
 the incubation process where guidance can have the most positive effect on
 a young project.
 
 
 Whether I am elected or not, I will continue working towards these goals.
 It has been, and continues to be, a pleasure to work with such a vast and
 vibrant community.
 
 Devananda
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC candidacy

2014-04-16 Thread Tristan Cacqueray

confirmed

On 04/16/2014 04:53 AM, Joe Gordon wrote:
 Hi All,
 
 I'd like to announce my candidacy for the Technical Committee election.
 
 About Me
 --
 
 I work full time on OpenStack on behalf of HP. And am part of nova-core,
 nova-specs-core, hacking-core and elastic-recheck-core. Some of my more
 visible accomplishments outside my involvement in nova are:
 
 - Creating hacking [0][1] to more efficiently use reviewers time by
 automating the tedious job of checking style.
 
 - Starting elastic-recheck [2][3] to help us better track and triage race
 conditions.
 
 - Helping Unwedge the gate right before the release of Havana [4].
 
 - Writing several gating jobs: large-ops, neutron-large-ops and nova’s
 partial-ncpu. partial-ncpu is nova’s gating test to make sure we support
  doing a rolling upgrade of compute nodes (so a Havana nova-compute should
 work with an Icehouse cloud).
 
 
 
 My Platform
 
 --
 
 
 I think the Icehouse TC has done a wonderful job and has an impressive list
 of accomplishments [4], and I would like to see the TC do more of the same
 at an accelerated pace. Given the scale of OpenStack today I don’t think
 sitting on the TC should be a two hour a week job. Note: I am not pushing
 for more frequent meetings, but rather more ‘homework.’ Two hours a week
 was fine when OpenStack had 3 integrated projects, but not so much now that
 we are at 11 integrated projects. Besides just doing more of the same, here
 are a few specific areas where I think the TC can be improved:
 
 - Make the mid-cycle incubation status reviews [6] more thorough, and
 extend them to projects that are planning on filing for incubation. We
 don’t want a repeat of what happened this past cycle where a project passed
 its mid-cycle incubation status review [6], only to hit significant issues
 in its graduation request [7]. - TC members who are not too familiar with
 the project in question should do the gap analysis instead of a member of
 that project. A fresh pair of eyes is always a good thing, and this will
 help increase cross project feedback.
 
 
 
 Thank you for your consideration.
 
 
 Best,
 
 Joe
 
 
 
 [0] http://git.openstack.org/cgit/openstack-dev/hacking
 
 [1] http://docs.openstack.org/developer/hacking/
 
 [2] http://git.openstack.org/cgit/openstack-infra/elastic-recheck/
 
 [3] http://status.openstack.org/elastic-recheck/
 
 [4]
 http://lists.openstack.org/pipermail/openstack-dev/2013-November/020280.html
 [5]
 http://lists.openstack.org/pipermail/openstack-dev/2014-April/032576.html[6]
 http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-01-21-20.03.html[7]
 http://lists.openstack.org/pipermail/openstack-dev/2014-March/030638.html
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




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

Re: [openstack-dev] TC Candidacy

2014-04-16 Thread Anita Kuno

confirmed

On 04/16/2014 12:47 PM, Sergey Lukjanov wrote:
 Hi folks,
 
 I'd like to announce my candidacy for the TC.
 
 I have been actively involved in OpenStack for about last two years,
 and before that I was in observer mode since Diablo timeframe. I’m PTL
 of OpenStack Data Processing program (Sahara project) from its very
 beginning. Additionally, I’m the core reviewer in the OpenStack
 Infrastructure team. I have contributions to different OpenStack
 projects including Oslo, Swift, Nova client, Hacking, Pbr, Jeepyb,
 Zuul and etc., you can find more info here [1].
 
 My main focus in OpenStack is to enrich the portfolio of services it
 provides with platform-level functionality, making it easier to use
 for application developers and encouraging faster and larger adoption
 of OpenStack platform. In addition to OpenStack I have contributed to
 other open source projects including Twitter Storm [2] and Kotlin [3].
 
 I see OpenStack not just an IaaS, but a great community, huge
 ecosystem of extremely fast growing projects integrated with each
 other to provide one consistent cloud platform. And here I see an
 opportunity to enhance ecosystem further by creating integration
 framework with other open source initiatives and their communities.
 Integration with Apache Hadoop community through Sahara project is an
 example. Sahara has been successfully graduated from the incubation by
 OpenStack Technical Committee decision in the mid March to become a
 part of integrated Juno release.
 
 As a TC member I would like to bring additional expertise to the Big
 Data in the OpenStack context and help to build a great and innovative
 platform. In Icehouse I was participating in the formalisation of the
 requirements for the incubation and graduation (as much, as it was
 possible for non-TC member). That’s why I’d like to continue working
 on it as I have a successful experience of growing project from
 scratch to integration in present days. So, the goal of my TC
 membership is to continue working on the OpenStack to help it grow
 further and to make it as friendly and clear for newcomer projects and
 contributors as possible.
 
 [1] http://www.stackalytics.com/?release=alluser_id=slukjanov
 [2] http://storm-project.net
 [3] http://kotlin.jetbrains.org
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy

confirmed

On 04/15/2014 03:07 AM, Angus Salkeld wrote:
 Hi all,
 
 I'd like to announce my candidacy as a TC member.
 
 A little about me:
 I am a software developer at Rackspace (previously at Red Hat). I
 started off my OpenStack
 contributions with Heat (I started Heat with Steve Dake). I have also
 have make some significant contirbutions to Ceilometer and I am now
 working mostly fulltime on Solum.
 
 What I'd like to focus on within the TC:
 I'd like to help/encourage the upper layer projects (heat, murano,
 mistral, solum, ...) so that they
 1) fit into OpenStack in a sensible way
 2) make sure we have the organisational structures in place to encourage
developers to work better together to deliver features that actually
 make sense to end users
and don't just confuse everyone.
 3) if they want to integrate, help communication between the project
 and the TC
 
 We have developers in this community doing some amazing work, but I
 think we need
 some better mechanisms for ongoing cross project communication (or
 possibly a different
 programme structure) that makes it easier to see what these new
 projects are doing
 and how it all fits together. I'd like to see developers in these
 projects working more
 together so that we build features that are cohesive and projects that
 try to do one thing well.
 
 I think having more people on the TC that know these projects better can
 only be a good thing (note: I am not totally up to speed on Murano but
 aim to be).
 
 Regards
 Angus Salkeld
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




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

Re: [openstack-dev] TC candidacy

confirmed

On 04/15/2014 01:13 PM, Julien Danjou wrote:
 Hi there,
 
 I'd like to announce my candidacy as a TC member.
 
 I'm a software engineer, and started contributing to OpenStack 2.5 years
 ago. I've also been the Ceilometer PTL for the last year. And I've
 actually already seated at the TC last year.
 
 Within the TC, I'd like to focus on improving projects on the QA level,
 defining clear guidance on incubation/graduation and improving our
 user/operator experience. I think we can do better than that we do
 currently, and I'd love to weight in on that.
 
 Cheers,
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




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

Re: [openstack-dev] TC Candidacy

confirmed

On 04/15/2014 01:29 PM, Michael Still wrote:
 Hi.
 
 I'd also like to announce my TC candidacy. I am currently a member of
 the TC, and I would like to continue to serve.
 
 I first started hacking on Nova during the Diablo release, with my
 first code contributions appearing in the Essex release. Since then
 I've hacked mostly on Nova and Oslo, although I have also contributed
 to many other projects as my travels have required. For example, I've
 tried hard to keep various projects in sync with their imports of
 parts of Oslo I maintain.
 
 I work full time on OpenStack at Rackspace, leading a team of
 developers who work solely on upstream open source OpenStack. I am a
 Nova and Oslo core reviewer and the Nova PTL.
 
 I have been serving on the TC for the last year, and in the Icehouse
 release started acting as the liaison for the board defcore
 committee along with Anne Gentle. defcore is the board effort to
 define what parts of OpenStack we require vendors to ship in order to
 be able to use the OpenStack trade mark, so it involves both the board
 and the TC. That liaison relationship is very new and only starting to
 be effective now, so I'd like to keep working on that if you're
 willing to allow it.
 
 Cheers,
 Michael
 




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

Re: [openstack-dev] TC Candidacy

confirmed

On 04/15/2014 02:04 PM, Steven Hardy wrote:
 Hi all!
 
 I'd like to announce my candidacy to serve as a TC member.
 
 
 About me:
 
 I'm a software engineer at Red Hat, and have been working full-time on
 OpenStack for the last two years.  I've been heavily involved with the Heat
 project since before it was incubated, served as PTL for the Havana cycle,
 and remain one of the top contributors to the project.
 
 During Icehouse, I've been trying to improve my knowledge and involvement
 with other projects, in particular contributing fixes to keystone and
 working to improve Heat's functional testing via tempest.
 
 Platform:
 
 Working on orchestration provides a unique view of OpenStack - it's
 essential to learn at least a little bit about every other project, because
 orchestration integrates with everything.  This is an exciting challenge,
 and provides a pretty broad perspective on issues such as API and client
 consistency.
 
 I am of the opinion that OpenStack should be inclusive by default and,
 trademark considerations aside, should not be limited to a core of
 components.  Instead I see OpenStack developing into an increasingly
 powerful collection of abstractions, providing consistency for users and
 flexibility for deployers.  If elected I would strive to work as an
 advocate for new and recently graduated projects, seeking to identify
 common problems and opportunities for improved integration.
 
 The issues I would consider priorities were I to be elected are detailed
 below, the common theme is basically better communication, efficiency and
 reuse:
 
 1. API consistency and reuse
 
 I believe we're making great progress and improving API consistency but
 there are still challenges and opportunities, primarily around improving
 cross-project consistency, communication and reuse.  I see the TC's role
 here as primarily one of facilitating and encouraging cross-project
 discussion, providing direction and monitoring progress.
 
 Closely related to this is encouraging projects to more pro-actively
 collaborate via cross-project initiatives such as oslo.  Ultimately we all
 benefit if we can reduce duplication of effort and collaborate on shared
 solutions.
 
 I believe that the TC should be providing clear leadership and direction
 which encourages projects to avoid long term fragmentation as ultimately it
 harms the user community (users operators and deployers getting
 inconsistent experience) and developers (maintenance burden and lack of
 knowledge transfer between projects).
 
 Finally client API consistency should be improved, in particular working
 towards common solutions for version discovery and common version-agnositc
 interfaces which reduce the (IME considerable) pain users experience when
 API versions change.
 
 2. Mentoring of new projects
 
 Having experienced the incubation process, and subsequent rapid growth of
 the Heat project, I've got first-hand experience of the challenges
 experienced by new projects seeking to become part of OpenStack.  There is
 a lot of accumulated experience and knowledge in the community, and
 in many cases this lore is not documented for new projects and
 contributors.
 
 I think the TC should strive to encourage more active mentoring of new
 projects, by implementing a scheme where a representative from the
 incubated project is paired with a person experienced with the area related
 to a graduation requirement, over time this can lead to identifying areas of
 common confusion, improved documentation, and hopefully engage new
 contributors (and reviewers) to participate in components related to gate
 integration and testing.
 
 3. Review of current PTL model
 
 After serving as the Heat PTL for Havana, I was left with the (apparently
 not that uncommon) impression that there are aspects of the PTL role and
 responsibilities which are sub-optimal for a diverse open-source project.
 
 As such, I would propose a review of the current model, where a PTL's
 primary function is release management and coordination, not really
 technical leadership in many cases.
 
 I would encourage consideration of a move to a subsystem maintainer
 structure, similar to that used for the Linux kernel, where individual
 projects and project sub-components are afforded more autonomy and less
 granular management, in exchange for an increased requirement for
 participation in automated gate integration testing.
 
 There may be other alternative solutions, but I believe it's time to
 initiate some discussion around what may be the most effective and
 appropriate strategy for project release management and leadership in an
 increasingly diverse and fast-moving environment.
 
 Thanks for your consideration!
 
 --
 Steve Hardy
 Red Hat Engineering, Cloud
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 




signature.asc

Re: [openstack-dev] TC Candidacy

confirmed

On 04/15/2014 02:18 PM, Jay Pipes wrote:
 Hi Stackers,
 
 I've known OpenStack since it was a baby, and I've watched it grow to
 the teenager it is today -- pimples and all. I hope to help guide it
 along its way to adulthood by serving on the Technical Committee.
 
 Besides developing on a number of core and ecosystem OpenStack projects,
 I've also spent a couple years on the deployment and operator side of
 the coin, which I think gives me a well-balanced perspective on some of
 the hardships that go hand in hand with configuring, upgrading and
 scaling a highly distributed piece of software.
 
 I think it's pretty well-known that I live and breathe a utility cloud
 world-view (all hail Cow29118281!). But hopefully it's also known that
 I'm open to other viewpoints, welcome discussion on ideological
 incongruence, and try to treat all folks with respect and dignity.
 
 On the TC, I would be a strong voice for:
 
  * Newcomers to the developer and operator community -- I'd like to help
 foster mentoring opportunities in the community and spread knowledge in
 a viral way
 
  * Simplicity and consistency in our public REST APIs -- The APIs are
 our public face, and when they are overly complex, inconsistent, or just
 don't make sense, we turn possible newcomers away from OpenStack. We
 should do everything we can to break down any barriers to entry to our
 wonderful community and fantastic set of projects
 
 Thanks for reading!
 
 -jay
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 




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

Re: [openstack-dev] TC Candidacy

confirmed

On 04/15/2014 04:03 PM, John Garbutt wrote:
 Hi.
 
 I would like to announce my TC candidacy.
 
 I work full time as a Software Developer on OpenStack at Rackspace,
 part of the team working on Rackspace Cloud Servers, Rackspace's
 public cloud. I am a Nova core reviewer, a member of nova-drivers,
 leader of the XenAPI Nova sub-team, and the Nova blueprint czar.
 
 I have had a wide variety of experience around OpenStack that will
 help me to represent the views of the whole OpenStack community. I
 first started working with OpenStack back in late 2010, building a
 private cloud distribution at Citrix. Later I moved to working full
 time on improving how XenServer integrates with OpenStack, and created
 the XenAPI Nova sub-team. I am currently focusing on ensuring
 OpenStack continues to perform well when running at the massive scale
 needed for the Rackspace public cloud.
 
 Throughout my career I have been a passionate advocate of getting
 developers thinking about the people who use (and deploy) the software
 they create. If elected to the TC, I would look at what can be done to
 improve the relationship between OpenStack's users and developers.
 Nova's reform of blueprint reviews is a great example of things we can
 try to help users to influence the direction developers choose to
 take.
 
 Above all, as always, I will be working hard to ensure OpenStack
 continues to be same awesome community that made me excited to start
 work this morning, and welcomed me into the world of open source
 development and cloud computing back in late 2010.
 
 Thanks for reading!
 
 John
 
 IRC:johnthetubaguy
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 




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

Re: [openstack-dev] TC candidacy

confirmed

On 04/15/2014 08:45 PM, Vishvananda Ishaya wrote:
 Hello all,
 
 I’d like to announce my candidacy for the Technical Committee election.
 
 I was one of the original authors of the Nova project and served as
 its PTL for the first two years that the position existed. I have also
 been on the Technical Comittee since its inception. I was also recently
 elected to the OpenStack Board. In my day job I am  the Chief Technical
 Officer for Nebula, a startup focused on bringing OpenStack to the
 Enterprise.
 
 My role in OpenStack has changed over time from being one of the top
 code contributors to more leadership and planning. I helped start both
 Cinder and Devstack. I’m on the stable-backports committee, and I’m
 currently working on an effort to bring Hierarchical Multitenancy to
 all of the OpenStack Projects. I also spend a lot of my time dealing
 with my companies customers, which are real operators and users of
 OpenStack.
 
 I think there are two major governance issues that need to be addressed
 in OpenStack. We’ve started having these discussions in both the Board
 and the Technical Committee, but some more effort is needed to drive
 them home.
 
 1. Stop the kitchen-sink approach. We are adding new projects like mad
 and in order to keep the quality of the integrated release high, we have
 to raise the bar to be come integrated. We made some changes over the
 past few months here.
 2. Better product management. This was a topic of discussion at the
 last board meeting and one we hope to continue at the joint meeting in
 Atlanta. We have a bit of a whole across openstack that is filled in
 most organizations by a product management team. We need to be more
 conscious of release quality and addressing customer issues. It isn’t
 exactly clear how something like this should happen in Open Source,
 but it is something we should try to address.
 
 I hope to be able to continue to address these issues on the Technical
 Committee and provide some much-needed understanding from the “old-days”
 of OpenStack. It is often helpful to know where you came from in order
 see the best direction to go next.
 
 Thanks,
 Vish Ishaya
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




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

Re: [openstack-dev] TC candidacy

confirmed

On 04/14/2014 05:59 AM, Thierry Carrez wrote:
 Hi everyone,
 
 I'd like to announce my candidacy for the Technical Committee election.
 
 I've been handling release management for the OpenStack project since
 2010. Release management is now an official OpenStack program
 (overseeing development cycle coordination, vulnerability management and
 stable branches maintenance), and I've just been reelected as its PTL.
 This position gives me a cross-project view on OpenStack which I think
 is essential to the work we do at the Technical Committee.
 
 With 10 integrated projects (11 in Juno!), release management is a bit
 of a full-time job, but I try to find time to contribute to various
 other parts of OpenStack, like the oslo.rootwrap library, the StoryBoard
 task tracker and other infrastructure projects.
 
 As the chair of the Technical Committee for the last 18 months, I tried
 my best to organize and coordinate the work of the committee. I'm proud
 of what the current TC membership achieved during the Icehouse cycle,
 including:
 
 - significantly raising the QA bar for accepting new projects
 - graduating Sahara in Juno and adding Barbican in incubation
 - getting involved on the technical side of the DefCore effort
 - setting up a governance repository to record policies and decisions
 - formalizing clear incubation and graduation requirements
 - review existing integrated projects compliance with those requirements
 
 Some of this work needs to continue over the Juno cycle, and new
 challenges are forming ahead. We need to continue supporting a measured
 growth for OpenStack projects, while solving the coordination and
 leadership challenges that it creates. As we grow larger, convergence in
 behavior, supported technologies, configuration or code used will help
 us reduce the overall technical debt. The Technical Committee is the
 right forum to drive that effort.
 
 Finally, the common OpenStack culture some of us old-timers take up for
 granted is not necessarily present everywhere in the project. This
 creates unnecessary friction between groups: we need to work on
 spreading that common culture and documenting the common values which
 will let us remain successful as our community of contributors grows in
 the future.
 
 Thank you for your consideration!
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy

2014-04-14 Thread Tristan Cacqueray

confirmed

On 04/14/2014 05:45 PM, Flavio Percoco wrote:
 Greetings,
 
 I'd like to announce my candidacy as a TC member
 
 I'm Flavio Percoco. I'm a Software Engineer working for Red Hat and
 I've had the pleasure to be part of this community for more than a
 year already.
 
 During this time, many things have happened that I summarized in the
 What I've done section. I've several plans for my time as a TC
 member - in case I'm elected - but in order to keep this candidacy
 concise, I've written the plans I consider most important
 community-wise in the Plans as TC Member section.
 
 During this last year, I've seen our community grow really fast in
 terms of programs, projects and contributors. Although this amazes me,
 it also makes me realize how important it is to have a vast number
 opinions in our community. Furthermore, it makes me realize how
 important it is to bring those opinions to the light, listen to other
 folks that haven't done so and act to keep the community consistent. I
 believe this is one of the keys of the success of our community and
 this candidacy is a proofs of this belief of mine. We must spread our
 efforts throughout the community in order to do so.
 What I've done
 ==
 
 My contributions to OpenStack started with Glance where I've dedicated
 a lot of time and efforts. This led me to contribute to Oslo, and then
 become a core contributor of it too. Contributing to Oslo has given me
 a wider view about what other projects needs are - w.r.t common code,
 libs and ways to do things - and this also helped me to understand how
 projects integrate with each other and gave me a more pragmatic idea
 of how things work and how they could be improved.
 
 While all this was happening, I was also contributing to one of the
 recently incubated projects, Marconi. Working on Marconi gave me a
 complete view of what new projects path is, what they need to
 accomplish before reaching incubation, what may make sense or not to
 have as an incubated project and which are the community and
 development standards that all projects should respect throughout
 OpenStack. I served as co-PTL of Marconi before it got incubated and,
 FWIW, I still do, although it's not an official role in OpenStack.
 
 In addition to the above, I'm also part of stable-maint team and I
 obviously work full-time on OpenStack.
 
 Plans as TC member
 ==
 
 Being part of a project that was integrated not-long-ago has helped me
 understand how difficult it can be for new projects to ramp-up, the
 importance of continuous communication with existing projects, groups
 and the TC itself. Moreover, this has helped me understand that we
 probably have a clear path for existing projects but the path for new
 projects is yet to be defined.
 
 One of my goals as a TC member will be to work on a better plan to
 support new projects in the vary phases those projects have to go
 through (pre-incubation, incubation and graduation).
 
 New projects will certainly bring new requirements that may change the
 base of what we know nowadays as the default OpenStack deployment.
 So far, we've done a great job with keeping projects consistent and
 reducing the differences between them technology-wise. Nevertheless,
 this process hasn't been defined concretely nor has it been discussed
 enough.
 
 Making sure this process is defined and that it embraces a broader
 community and technology diversity will be part of my main goals as a
 TC member. I believe technical consistency is a key for the success of
 projects like OpenStack and its community but so is diversity. Since
 both paths have a trade-off, we need to define our guidelines in
 between them.
 
 With all that said, it's quite obvious that along with new projects
 there will likely be new contributors as well. We've done a great job
 with trying to simplify the process for new contributors. However,
 there's still quite a technical gap that new contributors have to go
 through in order to ramp up.
 
 As part of my previous goal, I plan to work on making new
 contributor's ramp-up process easier and make sure there's support for
 them. I believe it is part of the TC responsibilities to make sure
 this gap doesn't exist.
 
 These goals can't happen without taking under consideration existing
 projects, programs and communities. Therefore, during my time as a TC
 member, I'll focus on helping existing projects to live as an example
 for new and future projects.
 
 Thanks for reading and considering this proposal.
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




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

Re: [openstack-dev] TC Candidacy

confirmed

On 04/14/2014 03:15 PM, James E. Blair wrote:
 Hi,
 
 I'd like to announce my candidacy for re-election to the TC.
 
 About Me
 
 
 I am the PTL for the OpenStack Infrastructure Program, which I have been
 helping to build for nearly three years.  I also served on the TC during
 the Icehouse cycle.
 
 I am responsible for a significant portion of our project infrastructure
 and developer workflow.  I set up gerrit, helped write git-review, and
 moved all of the OpenStack projects from bazaar to git.  All of that is
 to say that I've given a lot of thought and action to helping scale
 OpenStack to the number of projects and developers it has today.
 
 I also wrote zuul, nodepool, and devstack-gate to make sure that we are
 able to test all components of the project on every commit.  There are a
 lot of moving parts in OpenStack and I strongly believe that at the end
 of the day they need to work together as a cohesive whole.  A good deal
 of my technical work is focused on achieving that.
 
 Throughout my time working on OpenStack I have always put the needs of
 the whole project first, above those of any individual contributor,
 organization, or program.  I also believe in the values we have
 established as a project: open source, design, development, and
 community.  To that end, I have worked hard to ensure that the project
 infrastructure is run just like an OpenStack project, using the same
 tools and processes, and I think we've succeeding in creating one of the
 most open operational project infrastructures ever.
 
 My Platform
 ===
 
 An important shift has taken place since the convening of the first
 all-elected TC.  I am proud of what we have done to address important
 issues of consistency and quality that affect all of the projects.
 
 As we continue to add new projects and programs (at a measured pace),
 the role of the TC will need to continue to evolve to provide
 coordination and leadership in cross-project issues.  We have made a lot
 of progress on raising our expectations around testing, and there is
 more to do there.  The TC also has a role in improving user and operator
 experience by facilitating cross-project standards.
 
 Recently, the TC has begun to work with the Board of Directors on issues
 that concern us both.  The trademark issue is particularly important --
 it is no less than our identity as a project.  To me, the question is,
 what is the OpenStack community working to produce?  I believe that
 software derived from OpenStack with limited and reasonable
 modifications should be able to use the OpenStack trademark.  However, I
 do not believe our intent is to produce a crippled, open-core product.
 We are building one of the most significant open source systems and it
 is important that our name continue to stand for that.  I think the
 careful progress that the TC and Board have been making in this area
 will ultimately reflect that.
 
 I believe that the TC has been doing good work and is heading in the
 right direction for the project.  I would love to continue to help it do
 so and would appreciate your vote.
 
 Thanks,
 
 Jim
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy

confirmed

On 04/14/2014 04:41 PM, Mark McClain wrote:
 All-
 
 I'd like to announce my candidacy to continue serving on the Technical 
 Committee.
 
 
 Platform
 ---
 OpenStack is one community comprised of many parts and we must view ourselves 
 as one unit. As a TC member, I will continue to place the interests of the 
 larger community over those of those of individual projects.
 
 There are several key areas I'd like to see the TC focus on:
 
 Development
   The Technical Committee should serve as a high level forum to 
 facilitate defining cross project technical and procedural requirements. 
 While many of our programs share commonalities, there are still differences 
 in policies and technical decisions. The TC should continue its work to build 
 consensus and reduce the differences between the projects so the community 
 can function as one body.  
 
 Cross Project Communication
   Cross project communication is essential to maintaining a unified 
 stable OpenStack release.  When serving as PTL, I worked to facilitate a 
 mid-cycle meetup specifically designed to increase interaction between QA and 
 Networking teams.  I believe the TC should promote similar cross-project 
 initiatives where deep collaboration enhances the unity of our community.
 
 Process
   A recurring theme during the most recent term of the TC has been the 
 refinement of our program and project maturation process. The committee needs 
 to continue this work as it clarifies and strengthens the criteria used to 
 determine the kind of projects and programs that fit within the scope of 
 integrated releases and how they move through the progression of incubation 
 to graduation.  The growth of our community project ecosystem is very 
 exciting, but we’re currently limited in our ability to scale the number of 
 incubated projects.  The TC should examine how we can better scale the number 
 of incubated projects while ensuring a successful integration into the 
 release process.
 
 Unified Experience
   For OpenStack to be successful we must strive to provide a unified 
 experience for both users and deployers.  Users want tools that are well 
 documented and easy to use. The documentation and tools must be portable 
 across deployments (both public and private) so that users do not need to 
 concern themselves with the implementation details. At the same time, 
 deployers should be able to upgrade between releases and maintain a known 
 level of compatibility. Our community has invested significant effort to 
 improve this experience and this should remain a focus going forward.
 
 
 About Me
 -
 I am currently a member of the Technical Committee and a former PTL. 
 Believing that OpenStack is a unified community, I have contributed code and 
 reviews to nearly all of our integrated projects since my first contribution 
 during the Essex cycle. I believe that cross project contributions are 
 essential to foster collaboration and sharing of ideas within our community. 
 I'm a member of the Stable Release Team and the Requirements Team. My work on 
 both teams provides a cross project view of our community with an eye towards 
 stability and consistency.  Outside of development, I travel extensively to 
 advocate and educate on OpenStack and interact with our community of 
 developers, deployers and users.
 
 We have built a very special open community through the contributions of 
 many.  These contributions have powered our phenomenal growth and I'm excited 
 about our future!
 
 Thanks,
 mark
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy

confirmed

On 04/14/2014 07:11 PM, Morgan Fainberg wrote:
 Hi everyone!
 
 I would like to announce my candidacy for the Technical Committee election.
 
 About Me
 
 I’m Morgan Fainberg. I am a software engineer working for a startup focused 
 on deploying OpenStack in a private cloud configuration for a number of 
 organizations. I’ve been an active member of this community since the Essex 
 release. During my involvement in OpenStack, I’ve enjoyed collaborating on 
 many OpenStack projects via code contributions, active communication and 
 collaboration. Currently I am a member of the OpenStack Identity (Keystone) 
 Core team.
 
 I am always in many of the OpenStack IRC channels to keep a pulse on the 
 community and be available to provide assistance with development, QA, and 
 questions on OpenStack deployments.
 
 Platform
 ===
 As a developer, operator, deployer, and consumer of OpenStack, I have unique 
 insight on many different facets of OpenStack. This insight and experience 
 with our strengths and weaknesses in OpenStack allows me to work with the 
 community to improve user experience for developers and deployers. This 
 improvement of user experience includes on-boarding new contributors, making 
 deployments of OpenStack easier to manage, and helping to set direction 
 across project boundaries, and to help OpenStack improve and be more complete.
 
 There are some key points that I would like to see the TC focus on in the 
 immediate timeline.
 
 Performance and Concurrency
 ---
 A strong viable direction must be set forth on improvements and mitigating 
 regressions in performance across all OpenStack projects. This includes 
 trending, consistent testing, and even gating. There are specific projects 
 around tracking these metrics (notably Rally) which should be better 
 leveraged. The process, use of metrics, and availability of this data must be 
 formalized so that current, pre-incubated, and incubated projects will 
 perform at an acceptable standard in deployments of OpenStack.
 
 Inclusion of Operators in Design and Development
 --
 We need to be soliciting more feedback from the deployers and operators of 
 OpenStack. I view the Technical Committee as being ultimately responsible for 
 increasing the visibility of the demands of the users and operators so that 
 we (the community) can improve the usability of OpenStack. Overall, there has 
 been improvement, but in light of some of the discussions on the mailing list 
 (one example would be API major versions) we need to better include the 
 deployers, gaining a solid understanding of the impacts of a given change. 
 This concept extends further and includes improvement on the pre-incubation, 
 incubation, and integration requirements of new projects and programs. We’ve 
 seen improvement here but there is room for further discussion which should 
 absolutely involve operators to help make the best choices benefitting our 
 development community and the OpenStack deployment operators. The new 
 operator-focused sessions at the Summit are a start, but this effort will 
 require continue
d direction from the Technical Committee over the life of the development 
cycles.
 
 Cross Project Initiatives and Communication
 ---
 There has been an overall improvement of cross-project communication and 
 facilitation of cross-project initiatives. However, I believe that the 
 Technical Committee can continue improvement on this front. This should 
 include encouragement of mid-cycle meet-ups, with potential assistance from  
 OpenStack Foundation for facilitation and funding. This cross-project 
 communication is increasing in importance as we add more OpenStack programs 
 and projects. Some of these challenges are already addressed during the 
 cross-project (and release) meetings, however, the Technical Committee has a 
 unique role to enhance and formalize these channels.
 
 Ease of Deployment and Usability
 ---
 Each release of OpenStack has improved on deployment and usability of the 
 previous release. OpenStack as a whole must continue to drive toward better 
 user experience on all fronts and the Technical Committee is ultimately 
 responsible for defining goals and means to measure improvement for each 
 release. Each incremental improvement in usability encourages wider adoption 
 of OpenStack as a valuable solution to the Virtualization and Orchestration 
 problem spaces.
 
 
 It has been a privilege to be part of the OpenStack community, and I can’t 
 wait to see where the Juno cycle will take us. I look forward to continuing 
 to serve this community as a contributor, core member of the Identity 
 Program, and an advocate of improved usability and ease of deployment.
 
 Cheers,
 Morgan Fainberg
 
 
 
 ___

Re: [openstack-dev] TC Candidacy

2013-10-10 Thread Thierry Carrez

Robert Collins wrote:
 I'm interested in serving on the OpenStack TC.

Confirmed.

 
 # About me
 
 I've been working on OpenStack for only a year now, since joining
 Monty's merry gang of reprobateswink/ at HP. However I've been
 entirely focused on networking and distributed systems since ~2000 -
 having as highlights -core membership in the squid HTTP cache team,
 one of the founders of the Bazaar DVCS project, and a huge mix of
 testing and development efficiency thrown into the mix :). Earlier
 this year I was privileged to become a Python Software Foundation
 member, and I'm keen to see us collaborating more with upstream,
 particularly around testing.
 
 I live in New Zealand, giving me overlap with the US and with a lot of
 Asia, but talking with Europe requires planning :)
 
 # Platform
 
 At the recent TripleO sprint in Seattle I was told I should apply for
 the TC; after some soul searching, I think yes, I should :).
 
 Three key things occurred to me:
 
 All of our joint hard work to develop OpenStack is wasted if users
 can't actually obtain and deploy it. This is why we're working on
 making deployment a systematic, rigorous and repeatable upstream
 activity: we need to know as part of the CI gate that what we're
 developing is usable, in real world scenarios. This is a
 multi-component problem: we can't bolt 'be deployable' on after all
 the code is written : and thats why during the last two cycles I've
 been talking about the problems deploying from trunk at the summits,
 and will continue to do so. This cross-program, cross-project effort
 ties into the core of what we do, and it's imperative we have folk on
 the TC that are actually deploying OpenStack (TripleO is running a
 live cloud -https://wiki.openstack.org/wiki/TripleO/TripleOCloud- all
 TripleO devs are helping deploy a production cloud).
 
 I have a -lot- of testing experience, and ongoing unit and functional
 testing evolution will continue to play a significant role in
 OpenStack quality; the TC can help advise across all projects about
 automated testing; I'd be delighted to assist with that.
 
 Finally, and I'm going to quote Monty 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 should all hold: we're building an industry changing platform, and
 we need to think of the success of the whole platform as being *the*
 primary thing to aim for.
 
 Thank you for your consideration,
 Rob
 


-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC candidacy

2013-10-10 Thread Thierry Carrez

Chris Behrens wrote:
 Hi all,
 
 I'd like to announce my candidacy for a seat on the OpenStack
 Technical Committee.

Confirmed.

 
 - General background -
 
 I have over 15 years of experience designing and building distributed
 systems.  I am currently a Principal Engineer at Rackspace, where
 I have been for a little over 3 years now.  Most of my time at
 Rackspace has been spent working on OpenStack as both a developer
 and a technical leader.  My first week at Rackspace was spent at
 the very first OpenStack Design Summit in Austin where the project
 was announced.
 
 Prior to working at Rackspace, I held various roles over 14 years
 at Concentric Network Corporation/XO Communications including Senior
 Software Architect and eventually Director of Engineering.  My main
 focus there was on an award winning web/email hosting platform which
 we'd built to be extremely scalable and fault tolerant.  While my
 name is not on this patent, I was heavily involved with the development
 and design that led to US6611861.
 
 - Why am I interested? -
 
 This is my 3rd time running and I don't want to be considered a failure!
 
 But seriously, as I have mentioned in the past, I have strong
 feelings for OpenStack and I want to help as much as possible to
 take it to the next level.  I have a lot of technical knowledge and
 experience building scalable distributed systems.  I would like to
 use this knowledge for good, not evil.
 
 - OpenStack contributions -
 
 As I mentioned above, I was at the very first design summit, so
 I've been involved with the project from the beginning.  I started
 the initial work for nova-scheduler shortly after the project was
 opened.  I also implemented the RPC support for kombu, making sure
 to properly support reconnecting and so forth which didn't work
 quite so well with the carrot code.  I've contributed a number of
 improvements designed to make nova-api more performant.  I've worked
 on the filter scheduler as well as designing and implementing the
 first version of the Zones replacement that we named 'Cells'.  And
 most recently, I was involved in the design and implementation of
 the unified objects code in nova.
 
 During Icehouse, I'm hoping to focus on performance and stabilization
 while also helping to finish objects conversion.
 
 - Summary -
 
 I feel my years of experience contributing to and leading large scale
 technical projects along with my knowledge 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

Re: [openstack-dev] TC candidacy

2013-10-10 Thread Thierry Carrez

-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 Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSVtMtAAoJEFB6+JAlsQQjkyYQALXKqFAJ0L4/qJjLVCbdISLN
PfQsvXUa5hMN2LkQgfHr9+nH5QdSaFjMeKZTyqeOqAEpTQEw3HJs1lmUSkgH/FZY
C9wfHqybFWgpa4SbX+e9yEdKzfzELo3x6sjodSKi6FPAEJTWDMQ9UBLdM1K8z6ms
Z0CNxW3h/kMcDOuz5klqFF/rvwYA+OauagN7ECZcycmIPPeNaUow7vsKBUKXrUJT
TD7+X0mGiGu0GLtO/LVM2+fCFyBwNrdsHJMQCS4ZKr/dY8/pG3F94GDTeM9zrdW+
R5DULwYSyNAJ5IP3nBQN983EGsmdvYi0x+H+P6zRLXMNdBRukh3xKvwqQaQJ+yJI
48JEfe5rsgpgtkfDpEonfitEcMrklop2NoBtOBUgkUlnkOqL4r2AtYmXwGoXx7eA
lvAAarzk2JliUk+HHhB11sv9Oerp1DSjC36mpIW9+u1bI4UuKiIzt7ONsJFuhlRm
UqIe53Sx6AgWaJBYkVihSzJcjpr1jniVkeOHbV6WI7Bql8TyfGX4UnYWuTDJRtCF
qiSqe1TDe76BzrVkylUr+1dlHeS4uAK/xfjrgH9L2wyfBWb/G8+Jxjylt/RSLcZ4
aj+obRO75QubIF8jb2UQMwVaV06yRCMnVBzV5QUd/Ul3NAK+1zMsTFQG8QNnefYZ
Fp0pVCl1S8fMZpVcaFaL
=HmCt
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC candidacy

2013-10-10 Thread Anita Kuno

Confirmed.

On 10/10/2013 10:14 PM, Boris Pavlovic wrote:

Dear Stackers, I would like to put my candidacy for a position on the
OpenStack Technical Committee. I have been an active OpenStack
contributor for over a year, my work mostly concentrated around
improving existing OpenStack code (unifying common parts of OpenStack
projects and putting them to oslo, improving performance and test
coverage, fixing bugs). In the previous cycles I have been focusing on
improving OpenStack Database code, improving its performance, fixing a
lot of nasty bugs, making it more maintainable, durable and backward
compatible. I lead the community effort across all core projects to
centralize database

code into oslo-incubator (others will be switched in IceHouse). In
addition to being an active contributor, I spend a lot of time helping
newcomers to OpenStack to become better Open Source citizens. During
Havana I coordinated the activies of 16 of my team members across
several projects (nova, oslo, cinder and glance) which helped Mirantis
to make a meaningful contribution to OpenStack:
http://stackalytics.com/?release=havanametric=commitsproject_type=core
Currently I am focusing on the goal of consistently improving
OpenStack performance at scale, arguably one of the biggest challenges
across all of OpenStack. I believe that the problem with scale and
performance could be solved easily by the community. The main problem
is that contributors don't have an easy way to see how their commits
affect performance at scale. This is why two months ago (with the help
of four of my colleagues) I started work on project Rally (The
OpenStack Benchmark System). Rally allows everyone to see, close to
real life, the performance of the OpenStack cloud at scale. This
system will be closely integrated with the existing OpenStack CI,
making the process of tuning OpenStack scalability and performance
simple and transparent for everybody.

Next Monday, in collaboration with our colleagues from Bluehost and
IBM, we are going to release the first version of Rally.

I believe that at this point in time, the focus of the community ought
to shift to enabling our customers to adopt OpenStack in real
production use cases. This means that such issues as performance,
quality, reliability, maintainability and scalability should get a
higher priority, and as a member of the OpenStack TC, I would like to
become a strong advocate for making OpenStack production ready. Links:
1. Rally Wiki https://wiki.openstack.org/wiki/Rally

2. Rally Launchpad https://launchpad.net/rally

3. Example of Rally results:
https://docs.google.com/a/mirantis.com/file/d/0B7XIUFtx6EISTEpPb0tRSTFIaFk/edit?usp=drive_web
3. My Launchpad https://launchpad.net/~boris-42
https://launchpad.net/%7Eboris-42 4. My Contribution
https://review.openstack.org/#/q/owner:boris-42+status:merged,n,z 5.
My Contribution statistics:
http://stackalytics.com/?release=allmetric=commitsproject_type=Alluser_id=boris-42

Best regards, Boris Pavlovic --- Mirantis Inc.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy

2013-10-08 Thread Thierry Carrez

Confirmed.

Justin Shepherd wrote:
 I'd like to announce my candidacy for the TC.
 
 About Me
 
 
 I have been involved with OpenStack since the Bexar development cycle, and 
 have contributed to most of the programs along the way. I have also been in 
 attendance at every summit since the Cactus summit. My focus in OpenStack has 
 been on the usability and functionality of the stack (with an operators 
 viewpoint). On the installation and configuration side of things, I have been 
 heavily involved in the stack forge chef-cookbooks project, as a contributor 
 and core reviewer. Over the last development cycle, I have participated in 
 the TC acting as a proxy representative for Dolph Mathews.
 
 
 Platform
 ===
 
 As OpenStack continues to mature, I believe the TC has a major undertaking 
 ahead of it. 
 
 1. Continuing to define the layers of the OpenStack ecosystem is a huge area 
 for impact to the OpenStack user community. Clearly laying out the 
 requirements and expectations for the programs entering and exiting the 
 incubation phase will require a broad view of the project as a whole. This 
 will require a lot of interaction between the TC, PTLs, and the UC to make 
 sure that OpenStack continues solving problems for the user and operator 
 communities.
 
 2. Pushing performance as a first order concern. The developer community 
 needs to have better insight into how a change impacts each component. Right 
 now it is unclear how a specific commit to any of the projects impacts the 
 performance of either that project or the cloud as a whole.
 
 
 These are a few points that I think are extremely important 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 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

Re: [openstack-dev] TC Candidacy


Confirmed.

On 10/07/2013 04:30 AM, Flavio Percoco wrote:

I would like to propose my candidacy for the OpenStack Technical
Committee.


== What I've done ==

I've been involved with OpenStack for almost a year now and although
it may not seem a very long time, I've been able to contribute to
most of OpenStack areas.

My contributions to OpenStack started with Glance where I dedicated a
lot of time and efforts trying to make it better and to align it with
other OpenStack models. This led me to contribute to Oslo, and then
become a core contributor of it. Contributing to Oslo has given me a
wider view about what other projects needs are - w.r.t common code,
libs and ways to do things - and this also helped me to understand how
projects integrate with each other and gave me a more pragmatic idea
of how things work and how they could be improved.

While all this was happening, I was also contributing to one of the
recently incubated projects, Marconi. Working on Marconi gave me a
complete view of what new projects path is, what they need to
accomplish before reaching incubation, what may make sense or not to
have as an incubated project and which are the community and
development standards that all projects should respect throughout
OpenStack. I served as co-PTL of Marconi before it got incubated and,
FWIW, I still do, although it's not an official role in OpenStack.

In addition to the above, I'm also part of stable-maint team and I
obviously work full-time on OpenStack.

== Plans as TC member ==

My main goal as a TC member is to provide an objective, openstack-wise
opinion thanks to the wide view of it I've gained during my last year
of contributions and the teams I'm member of.

With that in mind, I'd like to help new projects to fit into OpenStack
and provide some guidance and support to existing projects either to
help then get out of incubation or stay on track with what OpenStack
is.

As a TC member, I'll always put OpenStack's interests on top of
anything else and use that to help other projects to grow.

As part of helping OpenStack overall, I will emphasize the need
of stability and make sure we do our best to preserve it and perhaps
improve the process.

Thanks for reading this email. I'd be very honored to serve as a TC
member and help this project grow with the same dedication and passion
I've had in the time I've contributed to it.

Cheers,
FF

--
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy


Confirmed.

On 10/07/2013 05:18 AM, Julien Danjou wrote:

Hi there,

I'd like to announce my candidacy for the TC.

About me

I've been working on OpenStack for 2 years now. I'm one of the early
contributors to the Ceilometer project, and worked towards its
incubation and integration. Now, I am the PTL for Ceilometer since the
Havana cycle.

Nowadays I work on various area of OpenStack, while still focusing on
Ceilometer. I've been also nominated and became a core contributor for
Oslo recently.

Outside OpenStack, I've been a FOSS contributor for the last 15 years in
various other projects (Debian, Freedesktop, Emacs...). I like to think
that I know a lot about the dynamics that make FOSS working and how to
build and organize successful open source projects.


Platform

I've been member of the TC for last 6 months. I've seen the enthusiasm
that drives people towards OpenStack, and the amount of incubation
proposal for projects that we received. Dealing with these requests has
been a major feature of the TC these last months, and I expect it to
continue this way. Especially because the TC chose to incubate a few
projects already, and judging if they are ready to go out of incubation
will be its duty. I hope that my experience could help in this regard.

On this issue, I've been really open minded and I think OpenStack should
generally welcome the incubation of projects, while setting right
correct criteria for projects to become integrated. Such standards
should be integration with other projects, reusability of work done, or
reduction of overlaps.

I don't envision OpenStack as a IaaS-only platform, but as an ecosystem
of coherent projects plugged together, providing services and solutions
to end users.

More generally, as a TC member I will continue to work to make OpenStack
the success it is and to be sure it continues to grow, connect with
friendly projects, and remain a welcoming technical community.

Cheers,


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy


Confirmed.

On 10/07/2013 06:19 AM, Sean Dague wrote:

I'd like to announce my candidacy for the TC.

About me

I've been involved in OpenStack since early 2012. I'm currently the 
PTL for the OpenStack QA program, and a core reviewer on Tempest, 
Devstack, Nova, Grenade, and a myriad of smaller pieces of OpenStack 
infrastructure (including hacking and elastic-recheck). [1][2]


My focus in OpenStack has been about making OpenStack work as a 
consistent whole, both from a runtime and development perspective. I 
believe this consistency, and the idea of OpenStack being one project 
(with many moving parts) is important to the long term health of the 
community. This has let me to focus on the projects that integrate us, 
the QA Program, Devstack, and parts of the gate infrastructure, and 
things like the wsgi log filter on logs.openstack.org.


Beyond OpenStack I've had a long history of contributing to Open 
Source projects both as part of my day job and on my own time. [3][4]


I've been involved in organizing communities for over a decade, 
creating and leading our local Linux  Open Source users group back in 
2003 and running it ever since. [5]



Platform
-
This view of OpenStack as a single whole is the reason I've focussed 
on the QA Program, as I feel that our gate infrastructure, and the 
integration tests that we choose to run there, is an incredibly 
important lens that ensures OpenStack hangs together as a whole.


This one OpenStack POV has also manifested itself in efforts like the 
global-requirements testing, one of my top projects this summer, where 
we now ensure all our projects actually are gating with a shared 
global list of requirements, so we know they all work together in a 
consistent way.


I'm excited by the growth of projects applying for incubation, but as 
the global requirements exercise showed, the more moving parts 
OpenStack, the more important we prove they integrate well with each 
other before they are graduated to integrated status. I think it's 
important that this remains expressed in code, which has always been 
the currency of OpenStack. Today that implementation lens for 
integration is devstack/tempest, tomorrow this may be something 
different, to meet the growing needs of the projects, but I still 
think it's important that we've got a single lens that brings all of 
Integrated OpenStack together, and that we can demonstrate it really is.


Integration is important, and ensuring that existing integrated 
projects remain integrated, and future ones really are integrated 
before we promote them, is my primary concern.


I'm incredibly excited by OpenStack's growth (in people, code, scope), 
which I attribute to an incredibly welcoming and constructive 
community, and the velocity we get out of our preemptive integration 
system. As a TC member I'd do my best to ensure those conditions 
remain. I think we've only just begun to see what OpenStack will 
become, and I'd be honored to be elected to the TC to help in all ways 
I can with it.


-Sean

[1] - contribution list to OpenStack - 
https://review.openstack.org/#/q/status:merged+owner:sean%2540dague.net,n,z
[2] - review list for OpenStack - 
https://review.openstack.org/#/q/reviewer:sean%2540dague.net,n,z

[3] - https://www.ohloh.net/accounts/sdague
[4] - https://github.com/sdague/
[5] - http://mhvlug.org




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC candidacy


Confirmed.

On 10/07/2013 10:58 AM, Mark McLoughlin wrote:

Hi

I'd like to offer my self as a candidate for the Technical Committee
election.


About me

I've been working on OpenStack for over two years now and have
particularly focused my contributions on Nova and Oslo, but have also
contributed in smaller ways to most other OpenStack projects.

For the past year or more, I've been a member of the Technical Committee
as Oslo PTL.

I'm a proud Red Hatter and am also a member of the OpenStack Foundation
Board of Directors.


The Past Year

I'm very happy with some of the progress and decisions the TC made over
the past year.

We welcomed Heat, Ceilometer, Trove, Savannah, Marconi into the
OpenStack family either as integrated or incubating projects. The TC
carefully considered each of these applications and my own rule of thumb
was does it have a healthy contributor community and is it a sensible
growth of OpenStack's scope?. I love to see this sustainable growth in
our project and community.

In a similar vein, I'm really excited that TripleO has been added as an
official OpenStack program. One of OpenStack's biggest criticisms has
always been that it is difficult to deploy and manage. TripleO is an
awesome idea but, more importantly, is a way for all of us to work
together to build tools and processes for deploying and managing our
software.

In terms of more meta changes, I'm really happy that the TC has moved to
a model where all seats are directly elected. This removed the concern
that adding new projects would make the TC unmanageably large so that
can no longer be used as an excuse to not add new projects. I also hope
that this election model will result in more members who are interested
in cross-project concerns.

I'm proud of the work we did with the foundation board to adopt the term
integrated as a way to separate the TC controlled accepted into the
OpenStack integrated release process status from the board controlled
allowed to use associate OpenStack trademark status. This is really
important because it allows the TC to evaluate new project applications
on a purely technical basis.

I think it's really positive that we adopted the concept of programs
as a recognition that not all important efforts and contributor groups
are focused around a particular server project. Our community has a very
diverse set of contributor groups and all of them play an important
role.

Finally, I'm happy to see us starting to use gerrit to track TC
decisions in a way that is easily referenceable. Looking back over the
last year of TC decisions would have been a lot easier with 'git log'!
See https://review.openstack.org/50066 :)


Next Year

I want to see the TC continue to be welcoming to new projects and
contributor groups. That said, I'd like us to continue improve how we
deliberate over these applications. For example, maybe we assign
specific TC members with aspects of the project to report back on - e.g.
architecture, development process, contributor diversity, test coverage,
etc.

I'm also really eager to encourage any experiments with evolving our
project governance model. I think we're seeing several projects with
multiple leaders who are essentially peers and having to choose a PTL
can be an artificial elevation of one person over their peers. I stepped
down as Oslo PTL because I want Oslo to have a bunch of strong leaders,
rather than be dominated by one person.

Finally, I'd like the TC to be used more often as a forum for people to
develop their ideas about the project. We should view the TC as a group
of project leaders who are happy, as a group, to help people out with
advice and mentorship.


Thanks,
Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy


Confirmed.

On 10/07/2013 10:57 AM, Anne Gentle wrote:
Hi, I'd like to propose myself to serve on the Technical Committee for 
the upcoming election term.


== Who Am I? ==

I volunteer my best for OpenStack every day, and will continue to do 
so in the coming term. I currently serve as Documentation Program Lead 
and have been working on OpenStack at Rackspace since September 2010. 
My PTL candidacy statement is available at [1]. We continually improve 
the documentation by applying better processes and resources all the 
time, treating the documentation like the fast-moving code itself. We 
also serve the many audiences interested in OpenStack, deployers, 
operators, administrators, architects, cloud consumers, users and 
developers. I believe that participating companies who employ 
OpenStack coders should also dedicate technical documentation 
resources, and am pleased to see member companies are getting the 
message and creating and recruiting for those positions.


== Why Am I Technical Enough for the TC? ==

I try to provide support through the docs in any way I can, by 
answering questions on IRC, Disqus doc comments, and on 
ask.openstack.org http://ask.openstack.org. My breadth and depth of 
knowledge is across OpenStack because of my role as Doc PTL.


I learn quickly and gather facts before passing judgement. In the last 
year, I have given fair attention to each incubation request and have 
tried to evaluate from the point of view of the audiences the docs serve.


I have built relationships across all of the OpenStack projects, 
giving doc platform and tooling support. I review doc patches from the 
perspective of all audiences, constantly asking for improvement.


During TC meetings, I ask the right questions and listen to the 
answers, asking further questions when my experience or vocabulary is 
lacking in an area. I admit when I don't know something. I work hard 
to earn trust and respect.


My goal is to provide an inclusive and supportive environment for 
projects while making OpenStack better for users and admins all the 
time. We are so fortunate to have the explosive growth and interest in 
OpenStack, and I want it to continue. We have built upon incredible 
ideas and I want us to be empowered to innovate.


I believe by serving on the Technical Committee I can continue to 
support OpenStack in meaningful ways.


Thanks for your attention, and thanks for all the important work that 
YOU, the members of our community, bring every day to this project.


Anne

1. 
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015465.html



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy


Confirmed.

On 10/07/2013 01:23 PM, Brad Topol wrote:

Hi Everyone,

I would like propose my candidacy for the OpenStack Technical Committee.

A bit about me

I have been an Active Technical Contributor to Keystone and DevStack 
since the Grizzly release.  I have also co-authored articles on 
OpenStack [1] and more information about me can be found in a recent 
OpenStack Open Mic article [2].In addition,  I lead and give 
direction to a large team of OpenStack developers at my company that 
contribute to a variety of OpenStack projects including Keystone, 
Heat, Ceilometer, Swift, Cinder, and Internationalization (i18n). This 
role gives me an opportunity to obtain a broad view of what is 
happening in the OpenStack projects as opposed to being focused on a 
specific core project.   I also spend a tremendous amount of time 
traveling to customers and business partners to evangelize OpenStack, 
listening to their OpenStack requirements and adoption impediments, 
and assisting their development teams to become contributors to 
OpenStack.  I am incredibly passionate about making sure OpenStack is 
highly consumable for our users  and that the OpenStack ecosystem 
grows and thrives.



Platform
===
As a technical team lead, developer, and evangelist for OpenStack,  I 
am deeply committed to OpenStack being incredibly valuable and 
consumable for all our users and also to making sure the OpenStack 
ecosystem grows and thrives.  I hear from customers all the time on 
how OpenStack can be improved such that it becomes easier to install, 
more consumable and serviceable, more easily integrated into 
enterprise customer environments,  and the need for being able to 
certify interoperability and scalability of OpenStack environments.  I 
would be honored to have an opportunity to serve as a member of the TC 
and to help drive the the technical direction of the OpenStack project 
based on all the outstanding feedback I receive from customers, 
business partners, analysts, and also from all the knowledge I have 
gained by both being a personal contributor to OpenStack as well as 
leading a large development team of strong and core contributors that 
work across several of OpenStack's core projects.


[1] - http://www.ibm.com/developerworks/cloud/library/cl-ldap-keystone/
[2] - 
https://www.openstack.org/blog/2013/08/open-mic-spotlight-brad-topol/


Thanks,

Brad

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Cindy Willman (919) 268-5296


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy

2013-10-07 Thread stever

+1 for Brad
-Original Message-
From: Brad Topol bto...@us.ibm.com
Date: Mon, 7 Oct 2013 13:23:30 
To: OpenStack Development Mailing Listopenstack-dev@lists.openstack.org
Reply-To: OpenStack Development Mailing List
 openstack-dev@lists.openstack.org
Subject: [openstack-dev]  TC Candidacy

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy


Confirmed.

On 10/07/2013 08:03 PM, Gabriel Hurley wrote:

I hereby announce my candidacy to continue serving on the Technical Committee.

My current qualifications:

   * Two prior terms actively engaged on the TC.
   * Horizon PTL for the Grizzly and Havana cycles.
   * Core Horizon developer since Essex, and Keystone Core since Folsom.
   * Author of the Core Values of Horizon: 
http://docs.openstack.org/developer/horizon/intro.html
   * Extensive depth and breadth of knowledge of all of the OpenStack projects 
and service APIs.
   * Aided both the OpenStack Translation team and the OpenStack UX Group in 
their initial formations and growth phases.
   * Ongoing advocate for OpenStack to provide a unified and sensible 
experience for end users.
   * Highly involved in discussions around the future of OpenStack.

Here are what I see as the two most important issues facing OpenStack:

1. Presenting a unified experience for OpenStack, across all programs/projects, 
all APIs, the dashboard, and the documentation would do a HUGE amount to 
improve what we offer to our users. The level of frustration that OpenStack's 
users endure on a regular basis due to our fragmentation is a true pain. I see 
it as the job of the Technical Committee to provide leadership across projects 
and to bear in mind the needs of the broader community in ways that individual 
projects may not have insights into.

2. The ongoing question of the scope of OpenStack is of critical importance. Recent TC 
discussion and votes on Savanna, Trove, etc. have shown just how unclear people are on 
the where the edges of OpenStack are. This question has no easy answers and I 
want to continue to try and define those boundaries in the way that best supports the 
broader ecosystem around OpenStack.

There are myriad other issues such as the engagement between the Foundation 
Board and the TC, coordination within OpenStack, and more, but I won't go into 
those now.

Hopefully I've proven myself thus far to be a considered and well-reasoned 
member of the TC. It would be my honor to consider doing the good work of 
OpenStack.

Thank you,

 - Gabriel Hurley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy