Re: [openstack-dev] OpenStack Programs
On 06/27/2013 12:54 PM, Stefano Maffulli wrote: On 06/27/2013 05:04 PM, Anne Gentle wrote: Let's do it! (On Thierry's timetable so that we get valuable practice talking about onboarding programs.) Sounds good to me as long as we all agree that Localization/Translations are a technical issue and that they're part of OpenStack's mission to empower people to build clouds. I think they are both a technical issue and important to our mission. I also think they are currently an edge case in several ways that we have been quite happily turning a blind eye to because there are a couple of really hard problems to solve from a tooling perspective, and for now we've valued getting stuff done over addressing the issues fully. Specifically here I'm referring to the combination of the issues of the CLA, contributor attribution, and ATC credit for translations work. I think it's worthwhile to dive in to this - it's just important to point out that there is a potential oubliette of amazingly exciting conversation on the topic that everyone is going to be thrilled to have. Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
On 06/24/2013 11:50 AM, Thierry Carrez wrote: To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) I think we should add Translations to the list of Programs: it is cross-functional to all the Projects, Incubated and Documentation (less relevant in QA and Infrastructure) but it has special needs, enough to deserve a small slot at the Design Summit, IMHO. Daisy: what do you think? /stef -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
Stefano Maffulli wrote: On 06/24/2013 11:50 AM, Thierry Carrez wrote: To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) I think we should add Translations to the list of Programs: it is cross-functional to all the Projects, Incubated and Documentation (less relevant in QA and Infrastructure) but it has special needs, enough to deserve a small slot at the Design Summit, IMHO. Daisy: what do you think? Translations is another horizontal effort, something that applies to all projects, like release management or vulnerability handling, but where contributions actually end up being applied as patches to other projects, rather than having their own repos. Another example of that would be the Python 3 effort. We have yet to decide if those should be considered programs, or if they should be recognized in some other way that is not a program. That shouldn't block the setup of the first programs though. Regards, -- 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] OpenStack Programs
On Wed, 2013-06-26 at 14:15 +0200, Thierry Carrez wrote: 4. Be potentially able to define a set of projects that are the OpenStack product (markmc) Random thought on this ... If one of the release deliverables was e.g. a openstack.org/havana page which included links to the tarballs of the server projects, the same for the client and oslo libs, and also links to the docs ... then that could be the definition of our product. The difficulty, of course, is that it's not actually all that useful as a starting point for users. Does anyone install the tarballs directly? So we'd need to make it clear that this is about documenting what's in the official OpenStack release rather than a starting page for users. Cheers, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
Mark Washenberger wrote: * There are efforts that span multiple projects but work directly on the project code repositories, like integrated release, or stable maintenance, or vulnerability management (collectively called for the convenience of this thread horizontal efforts). Should they be considered separate programs (without repos) ? Be lumped together into some catch-all integration or production program ? Or ignored as far as ATC status goes ? I've mixed feelings about that. On one hand I'd like those efforts visible and official to be more widely seen as a good way to contribute to OpenStack. On the other hand it's hard to tie ATC membership to those since we can't trace that back to commits to a specific repo Can you clarify this concern? Overall, folks would still be ATCs of the projects that they were committing on in the name of the given program, so their OpenStack ATC status would be successfully tracked regardless. Is the problem organizing leadership votes *within* the program? If so, could we settle on horizontal votes being extended to all OpenStack ATCs? or is that just too wide open? I'd rather have the same rules for every program and not start special-casing them. You want the leader of the team to be chosen by the members of the team, not by a vast majority of people external to the team. Maybe the simplest is just to keep those efforts separated from programs, but clearly document them. , and I'd like the programs mission statements to be precise rather than vague, so that the TC can bless them... Can you give an example of the kind of vagueness you're worried about? Perhaps it is just a failure of my imagination, but I can't seem to conceive of a way a program mission statement would be distinctly more vague than a project mission statement. I'm not really afraid of vagueness in general. I was afraid that if we tried to lump all horizontal efforts into a catch-all program, that catch-all program would have a rather weird-looking mission statement. That can be solved by creating separate programs rather than catch-alls. -- 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] OpenStack Programs
On 25 June 2013 20:19, Thierry Carrez thie...@openstack.org wrote: without a code repo today, so it's a moot point : I suggest saying that until it is revisited, there cannot be a Program w/o a code repo. What we have today is a number of efforts that are pretty central to OpenStack (like producing releases or maintaining stable branches) that do not appear in the new taxonomy. Those efforts don't have a code repository, they work with all code repos. Should those be considered separate programs ? A single production program ? Or not programs at all ? I see you advocate for the latter. All participants to those efforts are already ATCs since their work is done on other projects, so that's not a big problem in that respect. The main issue I see is that if it's not listed anywhere, that work is not really visible, which does not entice anyone to join those and help. Thanks for the explanation. I wasn't advocating for those efforts to not be programs, just that they shouldn't be programs *until* the governance aspect was sorted out - and as I wasn't clued into those efforts being large enough to make sorting out the governance aspect relevant in the short term - but perhaps it is and we should. So, doing [the 6 monthly] releases and stable branches seem like the same thing to me : it's packaging up the project output for consumption by redistributors (and low-resource risk-averse orgs). That totally makes sense to me as a program - but I think calling it 'production' would be a bit confusing, as TripleO is focused on production, whereas releases and stable branches are focused on distribution, IMNSHO :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
Robert Collins wrote: So, doing [the 6 monthly] releases and stable branches seem like the same thing to me : it's packaging up the project output for consumption by redistributors (and low-resource risk-averse orgs). That totally makes sense to me as a program - but I think calling it 'production' would be a bit confusing, as TripleO is focused on production, whereas releases and stable branches are focused on distribution, IMNSHO :) Aah... Naming, my favorite pastime :) Distribution makes sense, although it's a bit overloaded too. Integration is overloaded too. Delivery, maybe. Release and stable branch management is what we've been calling it so far, but it's a mouthful. We could potentially lump vulnerability management in the same program, since after all it's about handling and distributing security fixes, with a strong focus on stable branches. But since that's a different group that could warrant a separate program. -- 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] OpenStack Programs
Hey, On Mon, 2013-06-24 at 11:50 +0200, Thierry Carrez wrote: The TC would bless the *mission statement* of the program rather than the specific set of projects implemented to reach that goal. This is a really nice way of putting it and you've captured a bunch of other stuff very well too. The main thing I think about is the integrated release[1] - i.e. the categories I care about are officially part of the release and official and important OpenStack projects which aren't part of the release. Maybe this is just about a program's mission statement - as part of the mission statement, you explain what the program will contribute to the release. In the case of Oslo, it produces libraries to be included in the release. In the case of Infrastructure, it doesn't produce anything to be included in the release. In the case of TripleO, does it produce anything to be included in the release? I think it should, but it's not the entirety of its mission statement either. That, for me, is the really interesting thing to discuss about TripleO - what does it intend to produce for inclusion in the integrated release? In terms of incubation, you could say new projects that are intended for inclusion in the integrated release will go through incubation ... but that doesn't make sense in all cases. For example, there's not much value in new oslo libraries going through an incubation cycle because nothing would be able to use the library until it had exited incubation. Cheers, Mark. [1] - ok, some caveats on what I mean by integrated release ... We're producing software for people who want to build clouds. A software product, for want of a better term. Right now, we say the official service projects (definition: a project which exposes a REST API?) are integrated projects and that's what's contained in our release. I think we also say that Oslo libraries are part of the integrated release. The way I see it, our release is a product and should contain any official OpenStack software which provides a more complete experience for people deploying OpenStack clouds. The only change that would mean right now is that the client libraries and docs would be part of the integrated release. Even if there are some wonky details - like we have good reason to *also* release clients independently of the release cycle for a different set of target users (i.e. cloud users, not cloud builders) and that complete docs aren't a blocker for the integrated release going out - I think the release is weirdly incomplete without those considered a part of it. Also, before any jumps in with we shouldn't have releases, trunk should always be releasable ... that's mostly orthogonal. We'd still have a concept of an integrated product - which includes more than just the server products - which is always releaseable. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
On Mon, 2013-06-24 at 13:14 -0400, Monty Taylor wrote: * Where would openstack/requirements fall ? I think openstack/requirements sits under oslo - although right now it's a joint-venture between oslo and infra. If you look at the Oslo mission statement(s): https://wiki.openstack.org/wiki/Oslo The Oslo program produces a set of python libraries containing infrastructure code shared by OpenStack projects. The APIs provided by these libraries should be high quality, stable, consistent and generally useful. The Oslo program brings together generalist code reviewers and specialist API maintainers. They share a common interest in tackling copy-and-paste technical debt across the OpenStack project. then the overlap with openstack/requirements isn't at all obvious. Not to try and lump this solely on Thierry or anything, but I see this as a release/distribution management concern - the fundamental question is what external dependencies (and what version of those) is it sane for us to require in order to deploy OpenStack? Looking again at the review criteria: https://wiki.openstack.org/wiki/Requirements those questions are all about keeping a firm control over what external risks we expose ourselves (e.g. flakey upstreams) and that the dependency is compatible with our release goals (e.g. license, python version, distro availability). Cheers, Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
Anne Gentle wrote: Dare I ask, what about TryStack? Infra seems to get a ton under it but that's where I'd place it if I had to state a preference. I'd see TryStack as a separate program, with the goal of maintaining an infrastructure that lets users play with OpenStack. That goal sounds a bit parallel with the *development* infrastructure than the Infrastructure program maintains. Trystack would have to apply to become a program, though, since it's repositories (if any ?) are currently NOT considered official OpenStack stuff. -- 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] OpenStack Programs
Mark McLoughlin wrote: [1] - ok, some caveats on what I mean by integrated release ... We're producing software for people who want to build clouds. A software product, for want of a better term. Right now, we say the official service projects (definition: a project which exposes a REST API?) are integrated projects and that's what's contained in our release. I think we also say that Oslo libraries are part of the integrated release. I think I have a slightly different view. We as a project produce a number of deliverables. Some of those (the integrated projects) are released as a common, coordinated release at the end of our 6-month development cycles. The others (which include the python client libraries and the Oslo libraries) are released as-needed, although in some cases they borrow the same release cycle. I don't think we should start overloading the meaning of integrated. So the way I see it you would have teams, potentially producing deliverables. If one of those deliverables is to be part of the integrated release then you want to become a Project and you need to go through Incubation so that we check that you won't fuck up the rest of the integrated projects. If your team works on other deliverables (Documentation, Oslo libraries) or helps other teams (Infrastructure, Release) then you can apply to become a Program. All the deliverables from Projects + Programs are OpenStack deliverables and contributing to them grants you ATC status, and in return Projects and Programs are under the oversight of the TC. Do you think we need to distinguish between those deliverables, and tag some of them as being part of the OpenStack product, and some others as merely production helpers ? I'm not sure that would add a lot of value... -- 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] OpenStack Programs
On 06/25/2013 12:42 PM, Thierry Carrez wrote: Anne Gentle wrote: Dare I ask, what about TryStack? Infra seems to get a ton under it but that's where I'd place it if I had to state a preference. I'd see TryStack as a separate program, with the goal of maintaining an infrastructure that lets users play with OpenStack. That goal sounds a bit parallel with the *development* infrastructure than the Infrastructure program maintains. Trystack would have to apply to become a program, though, since it's repositories (if any ?) are currently NOT considered official OpenStack stuff. I agree, I do not think that trystack is a part of Infra. Same with refstack, which we discussed at the March board meeting and then again at the summit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
I like the programs idea and the direction this thread is going. As we reconsider the relationship of repos and programs to the OpenStack project, I think we should include one more aspect of taxonomy. We have several orgs on github related to openstack: openstack/ openstack-infra/ openstack-dev/ openstack-ci/ (defunct) We've traditionally only put (what we now call) components of the integrated release and their libraries in the openstack org. We put repos that relate to operation of the project infrastructure in openstack-infra, and everything else in openstack-dev (devstack, grenade, hacking, pbr, etc.). I propose that in the future, we adopt the following strategy: * Any repo associated with an official OpenStack program is entitled to use the openstack org. * Programs may request an org for their program, with justification, but in general we should limit the number of orgs in use. I expect that most of the repos currently under openstack-dev will belong to official projects and can be moved into openstack, and we can retire openstack-dev. I believe that the openstack-infra org is useful, particularly because of the large number of repositories, many of which have nothing to do with OpenStack itself. Because openstack-infra is concerned with the operation of the OpenStack project, we should continue to have a separate org for it. In the long run, I think the additional clarity around how programs and their repos relate to the OpenStack project will help us know where to put new repositories, and the reduced number of openstack-related organizations will help people find what they're looking for. -Jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
James E. Blair wrote: I propose that in the future, we adopt the following strategy: * Any repo associated with an official OpenStack program is entitled to use the openstack org. * Programs may request an org for their program, with justification, but in general we should limit the number of orgs in use. That's one way of doing it, although I find it a bit confusing. If you follow markmc's vision of having some repo deliveries tagged as being part of the OpenStack product, you could argue that the openstack/ org should be restricted to openstack product repos. That would be a convenient way of finding them. Alternatively you could limit the openstack/ org to projects and require that all programs set up their own org (like openstack-infra/). That way the orgs would mirror our taxonomy. I don't have strong feelings either way, and I think we can decide on that once the first programs are set up. -- 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] OpenStack Programs
Thanks for kicking off this discussion! I think the idea of programs has fantastic promise. On Mon, Jun 24, 2013 at 2:50 AM, Thierry Carrez thie...@openstack.orgwrote: Hi everyone, Official OpenStack projects are those under the oversight of the Technical Committee, and contributing to one grants you ATC status (which in turn you use to elect the Technical Committee members). The list of official projects used to be simple (Swift+Nova) but nowadays it is rather convoluted, with categories like integrated, incubated, library, gating and supporting, as described in [1]. That complexity derived from the need to special-case some projects because their PTL would automatically get a TC seat. Now that we simplified the TC membership, we can also simplify official projects nomenclature by blessing the goals rather than the specific repositories. [1] https://wiki.openstack.org/wiki/Projects This is why Monty had the idea of programs which would be blessed by the TC (and then any code under an official program becomes official). Rather than trying to come up with categories that would cover all the stuff that the Infrastructure team is working on (gating, supporting, libraries...), just say that Infrastructure is a program and let them add any repo that they need. The TC would bless the *mission statement* of the program rather than the specific set of projects implemented to reach that goal. That sounds like a pretty nice idea, so could we consider everything falls under the realm of a program ? Like having an integrated release program that would contain all integrated projects ? I think we need to keep special-casing a concept of projects, separated from programs, since those are accepted one by one by the TC and go through an incubation period. Those projects would contain at least one repo that wants to be part of the integrated, common OpenStack release, plus anything the same team works on (like the corresponding python client project). To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) New programs would draft a clear mission statement and apply to the TC for consideration. Programs should also expect to have a specific topic at the Design Summit (most of them already have), and should probably designate a lead/ambassador as a clear go-to person. A few questions I had left: * There are efforts that span multiple projects but work directly on the project code repositories, like integrated release, or stable maintenance, or vulnerability management (collectively called for the convenience of this thread horizontal efforts). Should they be considered separate programs (without repos) ? Be lumped together into some catch-all integration or production program ? Or ignored as far as ATC status goes ? I've mixed feelings about that. On one hand I'd like those efforts visible and official to be more widely seen as a good way to contribute to OpenStack. On the other hand it's hard to tie ATC membership to those since we can't trace that back to commits to a specific repo Can you clarify this concern? Overall, folks would still be ATCs of the projects that they were committing on in the name of the given program, so their OpenStack ATC status would be successfully tracked regardless. Is the problem organizing leadership votes *within* the program? If so, could we settle on horizontal votes being extended to all OpenStack ATCs? or is that just too wide open? , and I'd like the programs mission statements to be precise rather than vague, so that the TC can bless them... Can you give an example of the kind of vagueness you're worried about? Perhaps it is just a failure of my imagination, but I can't seem to conceive of a way a program mission statement would be distinctly more vague than a project mission statement. * Where would devstack fall ? QA program ? Infrastructure program ? * Where would openstack/requirements fall ? -- Thierry Carrez (ttx) ___ 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] OpenStack Programs
On 06/24/2013 05:50 AM, Thierry Carrez wrote: Hi everyone, Official OpenStack projects are those under the oversight of the Technical Committee, and contributing to one grants you ATC status (which in turn you use to elect the Technical Committee members). The list of official projects used to be simple (Swift+Nova) but nowadays it is rather convoluted, with categories like integrated, incubated, library, gating and supporting, as described in [1]. That complexity derived from the need to special-case some projects because their PTL would automatically get a TC seat. Now that we simplified the TC membership, we can also simplify official projects nomenclature by blessing the goals rather than the specific repositories. [1] https://wiki.openstack.org/wiki/Projects This is why Monty had the idea of programs which would be blessed by the TC (and then any code under an official program becomes official). Rather than trying to come up with categories that would cover all the stuff that the Infrastructure team is working on (gating, supporting, libraries...), just say that Infrastructure is a program and let them add any repo that they need. The TC would bless the *mission statement* of the program rather than the specific set of projects implemented to reach that goal. That sounds like a pretty nice idea, so could we consider everything falls under the realm of a program ? Like having an integrated release program that would contain all integrated projects ? I think we need to keep special-casing a concept of projects, separated from programs, since those are accepted one by one by the TC and go through an incubation period. Those projects would contain at least one repo that wants to be part of the integrated, common OpenStack release, plus anything the same team works on (like the corresponding python client project). To match with the current state we would end up with: * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder, Ceilometer, Heat) * Incubated projects (Trove, Ironic) * Programs (Oslo, Infrastructure, Documentation, QA) New programs would draft a clear mission statement and apply to the TC for consideration. Programs should also expect to have a specific topic at the Design Summit (most of them already have), and should probably designate a lead/ambassador as a clear go-to person. Thank you for describing the idea very well! I specifically like the idea of a program proposal drafting a mission statement and having a PTL. (infra and oslo both do PTLs, so I think it's a fair thing to except other programs to as well) A few questions I had left: * There are efforts that span multiple projects but work directly on the project code repositories, like integrated release, or stable maintenance, or vulnerability management (collectively called for the convenience of this thread horizontal efforts). Should they be considered separate programs (without repos) ? Be lumped together into some catch-all integration or production program ? Or ignored as far as ATC status goes ? I've mixed feelings about that. On one hand I'd like those efforts visible and official to be more widely seen as a good way to contribute to OpenStack. On the other hand it's hard to tie ATC membership to those since we can't trace that back to commits to a specific repo, and I'd like the programs mission statements to be precise rather than vague, so that the TC can bless them... I'd actually like to revisit this question as a separate thing. Honestly, I want to see bug work and review work as part of the ATC calculation. Seriously - both are hard and thankless. I think those are really the only two places where work on the above stuff can 'fall through the cracks' by potentially not having a 'patch'. * Where would devstack fall ? QA program ? Infrastructure program ? I think it's honestly a joint-venture between QA and Infra (especially if you consider developer tooling to fall into the infra umbrella - which is where it traditionally has fallen) But I'd say it's more primarily Infra and we use it for QA, rather than the other way around (as someone said the other day - it's devstack, not teststack or tempeststack) * Where would openstack/requirements fall ? I think openstack/requirements sits under oslo - although right now it's a joint-venture between oslo and infra. Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
