Re: [openstack-dev] TC Candidacy

2013-10-07 Thread Anita Kuno

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 Anita Kuno

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

2013-10-07 Thread Anita Kuno

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

2013-10-07 Thread Anita Kuno

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

2013-10-07 Thread Anita Kuno

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

2013-10-07 Thread Anita Kuno

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

2013-10-06 Thread Anita Kuno

Confirmed.

On 10/06/2013 04:04 AM, Michael Still wrote:

Greetings! I am currently a member of the TC, and I would like to
continue to serve.

I'm going to write this email backwards because I am aware it is quite
long. I have put what I hope to achieve on the TC at the top, but
provide background detail afterwards for those who want to dig deeper.
I am of course happy to answer questions.

== Executive summary ==

* I am a Nova and Oslo core reviewer, who works full time on upstream OpenStack
* Provide geographic diversity to the TC, doing my best to represent
the APAC region
* Continue to incubate new projects so long as they form a logical
part of a cloud deployment, regardless of whether they will graduate
within a single release
* We need to work on improving documentation, and I'd like to see the
TC work on this in Icehouse
* Assist the Foundation Board in defining "what is core" and placing
high quality technical evangelists at conferences around the world
* Also, I have a cool accent

== What I want to get done on the TC in Icehouse ==

First off, the TC has incubated a number of projects in the Havana
release, and I'd like to see that continue. I think its important that
we build a platform that includes the services that a deployer would
need to build a cloud and that those platform elements work well
together. Now, its clear that not everyone will deploy all of the
projects we are incubating, but I think its still important that they
play well together and have a consistent look and feel.

I suspect that ultimately we'll need to work out how to handle this
growth differently -- we have a lot of PTLs now and the summit is
going to be super busy, but these are both good problems to have and I
am confident that we can solve them as a community. I also do not
believe that an incubated project needs to graduate within one
release. I'd rather take a less mature project if we think it has a
good chance of getting to graduation in the forseeable future and work
with them, than ignore them and then be surprised that they never
became a well integrated project.

We need to get better at documentation, and the TC needs to do more in
this area. Having high quality documentation is very important to the
continued success of OpenStack. Anne Gentle and the docs team are
doing a fantastic job, but I am personally of the belief that the docs
team simply isn't big enough to keep up with the work load we impose
on them. I'd like to see the community, lead by the TC, discuss how we
can grow that team and produce the documentation the project deserves.
I've seen proposals that we block code reviews which don't have an
associated doc patch for example, and while I think that's too blunt a
metric we need to do _something_. Could we do something with reporting
the number of undocumented features are landing? Could we be better at
approaching corporate contributors and asking for more documentation
support?

The TC needs to also provide more assistance to the Foundation Board.
The reality is that the Board and TC don't solve isolated problems --
they both work on different aspects of the same problem. The Board has
been doing really good work, but the TC should be helping what defines
"core" OpenStack. While this discussion might be framed as being about
trademarks, it ultimately affects how users see our software and I
think that matters a lot to the technical people as well.

I'd also like the TC to be helping the Foundation place technical
talks at conferences around the world. We have a limited window to
drive OpenStack deployment, and having solid technical talks at as
many technical conferences around the world as possible is one of the
ways we can achieve that. While I'm lucky enough to work somewhere
with good support for these activities internally, that's not true of
all of our developers. The TC and Board should be working together to
identify high quality technical evangelists, and then helping them get
accepted at conferences. Perhaps the Board can also allocated some
travel support for this sort of activity -- I'd love to see that
happen.

Overall I think the TC should be helping the Board more. The TC has
unique insights into what projects and events matter to the technical
deployers of OpenStack, and we should be helping the Foundation make
good decisions. During the Havana release there was one meeting
between the TC and the Board (the day before the Havana summit opened)
that I am aware of, and I think we need to be talking more than that.

== Background ==

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 

Re: [openstack-dev] TC Candidacy

2013-10-05 Thread Anita Kuno

Confirmed.

On 10/05/2013 05:46 PM, Morgan Fainberg wrote:


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



A bit about me



I have been working with OpenStack in a professional capacity since 
before the Essex release and have participated in each of the summits 
since that time.  Throughout that timeframe I've been an active 
participant in most of the projects that make up OpenStack through 
active communication and collaboration. I am currently a member of the 
Keystone Core team and almost always available / active on IRC 
(ensuring I have a good pulse on most of the projects at any given time).



During the Havana cycle I have been mostly focused on Keystone, 
however, I have also contributed to a number of other OpenStack 
projects.  Over the last cycle, I have made sure to attend the TC 
meetings and keep apprised of the content discussed and decisions made.



Platform

===

As a developer, operator, and consumer of OpenStack, I believe that 
OpenStack (and, more generally speaking, IaaS) is the "way of the 
future" when it comes to managing and maintaining computational 
resources.  I think that OpenStack in particular is a defining force 
within this space, and as such has a responsibility to help the 
industry grow in a positive way.  This, in no small part, includes 
bringing new projects online (from incubation to full integration) to 
fill the gaps in functional coverage and ensuring that both new and 
already integrated projects are ready for prime-time use.



For the next couple of cycles (and beyond), I see the TC's role as not 
only growing the platform in a stable and maintainable way, but also 
being an active advocate for the diverse set of consumers of OpenStack 
(public cloud providers, private cloud providers, enterprise 
integration, development environments and platforms, QA environments, 
end consumers of the various cloud installations, etc).  The TC should 
continue to take an active role (in some cases more active) in the 
project-wide scope direction.  This active participation will include 
continued direct collaboration with the Board of Directors as well as 
the many contributors (both corporate and individual) of OpenStack.



The TC needs to have diverse representation from all corners of the 
community to ensure that we keep the project moving forward in a way 
that meets the real needs of all OpenStack users.  As part of the TC, 
I would bring the experience of running multiple diverse private 
clouds for large enterprises as well as an understanding of the need 
to maintain and grow the accessibility of OpenStack for all use cases.



I look forward to continue contributing as a member of the Keystone 
Core team and being a vocal advocate for increased usability and ease 
of deployment for all of OpenStack.  I would be honored to also serve 
as a member of the TC, collaborating, and helping to guide the 
technical direction of the project as a whole.



Cheers,
Morgan Fainberg


___
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-04 Thread Anita Kuno

Confirmed.

On 10/04/2013 06:46 PM, James E. Blair wrote:

Hi,

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

About Me


I am the PTL for the OpenStack Infrastructure Program, which I have been
helping to build for the past two years.

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 bzr 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
===

As a significant OpenStack user, I'm excited about the direction that
OpenStack is heading.  I'm glad that we're accepting new programs that
expand the scope of our project to make it more useful for everyone.  I
believe a major function of the Technical Committee is to curate and
shepherd new programs through the incubation process.  However, I
believe that it should be more involved than it has been.  We have been
very quick to promote out of integration some exciting new projects that
may not have been fully integrated.  As a member of the TC, I support
our continued growth, and I want to make sure that the ties that hold
our collection of projects together are strong, and more than just a
marketing umbrella.

I have also seen a shift since the formation of the OpenStack
Foundation.  Our project is a technical meritocracy, but when the
Foundation's board of directors was established, some issues of
project-wide scope have been taken up by the board of directors while
the Technical Committee has been content to limit their involvement.
The Foundation board is extremely valuable, and I want the Technical
Committee to work closely with them on issues that concern them both.

Adding new projects is not the only purpose of the TC, which is charged
in the bylaws as being responsible for all technical matters relating to
the project.  The reformation of the Technical Committee with an
all-elected membership provides an opportunity to strengthen the
technical meritocracy of the OpenStack project by electing people who
will execute the full mission of the TC.  I would be happy to serve in
that capacity 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

2013-10-04 Thread Anita Kuno

Confirmed.

On 10/04/2013 03:05 PM, Steven Dake wrote:
I would like to propose my candidacy for the OpenStack Technical 
Committee.


I originated and led the Heat project with a small team of core 
developers from Red Hat in early 2012.  I am also a core member of the 
Heat team and have contributed to Heat's progress through incubation 
and integration status.  My original vision for the leadership of the 
Heat project was based upon the book "The Starfish and The Spider" [1] 
in which decentralized organizations such as OpenStack harness natural 
consequences of emergent [2] systems.


I have a strong first-hand grasp of organizing small groups into 
producing great results and plan to act as a facilitator to projects 
that are seeking incubation or have become incubated and need a bit 
further help making their way into Integrated status in OpenStack.  My 
main objective serving in the Technical Committee is to help drive the 
growth of OpenStack through new project integration and growth.  I am 
also a firm believer in transparency and would strive to help the 
community in general understand the consensus and decisions of the 
Technical Committee.


I have a strong background in this area - having originated the open 
source projects Corosync [3] which serves as the underpinnings of high 
availability in Linux and other platforms as well as Heat which is 
near and dear to all of us working in OpenStack.  Given the success of 
both these projects which require a high degree of transparency and 
decentralized leadership, I believe I am a good match for serving the 
OpenStack community via the Technical Committee.


I would appreciate your vote for growing new OpenStack projects into 
full integrated status and improved TC transparency by serving the 
OpenStack community in the Technical Committee.


Kind Regards,
-steve

[1] http://en.wikipedia.org/wiki/The_Starfish_and_the_Spider
[2] http://en.wikipedia.org/wiki/Emergence
[3] https://github.com/corosync/corosync


___
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-04 Thread Anita Kuno

Confirmed.

On 10/04/2013 01:28 PM, Zane Bitter wrote:
I would like to propose my candidacy for the OpenStack Technical 
Committee.


I have been involved with OpenStack since we started the Heat project 
in early 2012. I'm still a member of the Heat Core team and - 
according to the semi-official statistics from Bitergia 
(http://bitergia.com/public/reports/openstack/2013_04_grizzly/), at 
least - among the more prolific patch contributors to OpenStack.


Over the last year I have often worked closely with the TC, beginning 
with helping to shepherd Heat through the incubation process. That 
process involved developing a consensus on the scope of the OpenStack 
project as a whole, and new procedures and definitions for incubating 
projects in OpenStack. These changes paved the way for projects like 
Trove, Marconi and Savanna to be incubated. I hope and expect that 
more projects will continue to follow in these footsteps.


I remain a reasonably frequent, if irregular, attendee at TC meetings 
- occasionally as a proxy for the Heat PTL, but more often just 
because I feel I can contribute. At this stage of its evolution, I 
think the main responsibility of the TC is to grow the OpenStack 
project in a responsible, sustainable way, so I take particular 
interest in discussions around incubation and graduation of new 
projects. Many new projects also have potential integration points 
with Heat, so having folks from the Heat core team involved seems 
valuable.


I also think that the TC could do more to communicate its inner 
workings (which are public but, I suspect, not widely read). While 
most decisions eventually come down to a vote and the results are 
reported, the most important work of the committee is not in voting 
but in building consensus. I believe the community would benefit from 
more insight into that process, and to that end I have started 
blogging about important decisions of the TC - not only the outcomes, 
but the reasons behind them and the issues that were considered along 
the way:


http://www.zerobanana.com/archive/2013/09/25#savanna-incubation
http://www.zerobanana.com/archive/2013/09/04#icehouse-incubation
http://www.zerobanana.com/archive/2013/08/07#non-relational-trove

These posts appear on Planet OpenStack and are regularly featured in 
the Community Newsletter, so I like to think that this is helping to 
bring the workings of the TC in front of an audience who might not 
otherwise be aware of them.


If elected, I'd like to act as an informal point of contact for 
projects that are already in incubation or are considering it, to help 
explain the incubation process and the committee's expectations around 
it.


I consider myself fortunate that my employer permits me to spend 
substantially all of my time on OpenStack, and that my colleagues and 
I have a clear mandate to do what we consider best for the _entire_ 
OpenStack community, because we know that we succeed only when 
everyone succeeds.


cheers,
Zane.

___
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-04 Thread Anita Kuno

Confirmed.

On 10/04/2013 11:14 AM, Monty Taylor wrote:

Hi all!

I would like to continue serving the project on the OpenStack TC.

Background
--

I've been with this bad boy since before day 1, and you can pretty much
blame me for trunk gating. You can also blame me for the bzr days - so
I'm not going to try to claim that I'm always right. :) I started and
until yesterday have been the PTL of the OpenStack Infrastructure team.
During my tenure there, we have grown what is quite possibly one of the
largest elastic build farms dedicated to a single project anywhere. More
importantly than large though, we've spent the effort to make as much of
our ops work as is possible completely open and able to receive changes
via code review in the exact same manner as the OpenStack projects
themselves.

The OpenStack Infrastructure system themselves are a scalable
application that runs across two clouds. This means that I am, as part
of that team, a very large user of OpenStack, which I believe gives me
an excellent perspective on what users of OpenStack might want. (hint:
vendor differences in how I get a sane hostname on a system I'm spinning
up - not what I want)

I work a LOT on cross-project coordination, compatibility and
automation. I have commits in every single OpenStack repo. In addition
to infra, have worked on pbr, hacking, openstack/requirements and
oslo.sphinx. I helped battle this cycle's setuptools/distribute re-merge
and ensuing upgrade nightmare. I landed patches in tox upstream to allow
us to skip the costly sdist step and use setup.py develop directly in
the virtualenv.

I'm also one of the only people who can have a conversation with ttx
about how our version numbers work and understand every nuance. I wrote
the code in pbr that encodes the design inside of ttx's brain.

Adjacent to OpenStack, I've managed to convince HP to fund me and a
group of merry troublemakers to work on OpenStack. One of the things
that has sprung from that is the TripleO project. I can't take credit
for any of the actual code there, but this is a TC candidacy, not a
developer cadidacy, and I think a large portion of being on the TC is
being able to steward the success of something both with and without
directly coding on it yourself.

I'm also a member of the Python Software Foundation and have been
working hard this cycle to start to align and integrate better with what
upstream Python do. Despite our intent to be good python people, it
turns out we do a bunch of things quite differently. Over time, I think
it would be better for those differences to decrease. I'm currently
working on writing my first PEP.

Platform


The following was said to me on IRC a couple of day ago. It was not
meant as a compliment, but I will take it as one, and I think it quite
explicitly sums up why I should be on the TC:

mordred: it is infact you who are thinking narrowly *only* considering
openstack's goals

I believe that OpenStack is "One Project". I believe it is in our best
interest to be one. I believe that the more we work together across the
projects, the more better OpenStack will be.

As a TC member, I will continue to strive to enhance the view that
OpenStack itself is an important thing and it not just a loose
confederation of friendly projects.

I have an expansive view of the scope of OpenStack. I do not think that
'pure IaaS' as a limiting factor in the definition serves or will serve
any of our users. I think that instead of trying to come up with random
or theoretical labels and then keeping ourselves inside of the
pre-defined label, we should focus on writing software that solves
problems for users. trove and savana are great examples of this. As a
user, I want to store my data in a database, and I want to run some
map-reduce work. I'm not interested in figuring out the best way to
administer a MySQL instance inside of a VM. So, as a user, a database
service helps me write scalable cloud-based applications, and having it
be part of OpenStack means I can write that scalable cloud-based
applications that span multiple clouds.

As a TC member, I will continue to support a viewpoint that a consistent
set of features across clouds is important to a user, and the more
features there are that the user can count on to be in all of the
OpenStack clouds, the better the user experience will be.

I believe that the users of clouds are our users, not just the deployers
of clouds. In fact, if I have to choose between the desires of the users
of clouds and the desires of deployers of clouds, I will choose in favor
of the users of clouds.

As a TC member, I will strive to consider the needs of the end users in
discussions we have about coordinated choices and overall shape of
OpenStack.

Lastly, as a person who only considers OpenStack's goals and does not
have a direct affiliation with any of the individual projects, I believe
I'm in a good position to mediate issues between projects should they
arise. Thus far, I do not b

<    1   2