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/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. /stef ___ 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'd really like to see Translation be the first program we bring in after bringing in the first batch. Translation and localization meets the criteria for a program. Their inclusion in a second round will help us learn how to bring in a valuable program, identify the right owners, and promote the advocacy roles in programs. Let's do it! (On Thierry's timetable so that we get valuable practice talking about onboarding programs.) On Thu, Jun 27, 2013 at 6:43 AM, Thierry Carrez wrote: > Stefano Maffulli wrote: > > On 06/27/2013 10:10 AM, Thierry Carrez wrote: > >> Mind you, I'm not closing the door or anything: translations can > >> certainly apply to become a program (once/when we establish them). The > >> goal of the "initial batch" is to catch up with the current state of > >> "official projects", not to come up with a definitive or closed list. > > > > Translations is already official project, and one that needs a strong > > push too. I think it should be considered for inclusion in the first > > batch of programs and integrated. > > No it's not, as far as the Technical Committee charter is concerned: > https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee > > That's why I think it should be discussed and considered as a second > (baby) step, so that we don't overload the initial proposal. > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Anne Gentle annegen...@justwriteclick.com ___ 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/27/2013 10:10 AM, Thierry Carrez wrote: >> Mind you, I'm not closing the door or anything: translations can >> certainly apply to become a program (once/when we establish them). The >> goal of the "initial batch" is to catch up with the current state of >> "official projects", not to come up with a definitive or closed list. > > Translations is already official project, and one that needs a strong > push too. I think it should be considered for inclusion in the first > batch of programs and integrated. No it's not, as far as the Technical Committee charter is concerned: https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee That's why I think it should be discussed and considered as a second (baby) step, so that we don't overload the initial proposal. -- 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/27/2013 10:10 AM, Thierry Carrez wrote: > It's not as clear of a slam dunk as the other (initial) programs due to > the nature of their "deliverable", which is consumed by the projects > themselves, so it's a bit of a corner case. Additionally, the reach of > the Technical Committee is supposedly limited to "technical" matters, so > we would have to rule that a message translation is a technical > contribution, and therefore under the oversight of the TC (rather than, > say, user committee or marketing team). Not saying it's not the case, > just saying we would need to discuss that in detail. Translations (should we say localization/internationalization?) are definitely a technical thing and require making technical choices. Just an example is the discussion about how to handle localization of messages (logs, debug, errors, etc). Also, localization and internalization of code and manuals require development of tools that integrate well with current development processes, much like for documentation (see for example the 'DocImpact' keyword in commit logs). > Mind you, I'm not closing the door or anything: translations can > certainly apply to become a program (once/when we establish them). The > goal of the "initial batch" is to catch up with the current state of > "official projects", not to come up with a definitive or closed list. Translations is already official project, and one that needs a strong push too. I think it should be considered for inclusion in the first batch of programs and integrated. /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
Tom Fifield wrote: >> 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, > > """ > 'OpenStack Programs' are efforts which are essential to the completion > of our mission, but which do not produce deliverables included in the > common release of OpenStack 'integrated' projects every 6 months, like > Projects do. > """ > > How is this not true of Translation? It's not as clear of a slam dunk as the other (initial) programs due to the nature of their "deliverable", which is consumed by the projects themselves, so it's a bit of a corner case. Additionally, the reach of the Technical Committee is supposedly limited to "technical" matters, so we would have to rule that a message translation is a technical contribution, and therefore under the oversight of the TC (rather than, say, user committee or marketing team). Not saying it's not the case, just saying we would need to discuss that in detail. Mind you, I'm not closing the door or anything: translations can certainly apply to become a program (once/when we establish them). The goal of the "initial batch" is to catch up with the current state of "official projects", not to come up with a definitive or closed list. -- 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 26/06/13 22:20, Thierry Carrez wrote: 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, """ 'OpenStack Programs' are efforts which are essential to the completion of our mission, but which do not produce deliverables included in the common release of OpenStack 'integrated' projects every 6 months, like Projects do. """ How is this not true of Translation? Our mission 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." It seems simple: we cannot be ubiquitous if we're only in English. Regards, Topm ___ 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/26/2013 08:20 AM, Thierry Carrez wrote: 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. Well, only sort of. Remember the actual translation efforts happen in transifex - https://www.transifex.com/projects/p/openstack/ and Jenkins completely strips attribution when it brings them in in chunks to the projects (as it's an automated job) -Sean -- Sean Dague http://dague.net ___ 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
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
James E. Blair wrote: > Thierry Carrez writes: >> James E. Blair wrote: >>> * 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. > > Honestly, my first thought was "hey, we can have the orgs mirror the > taxonomy, and that will be easy". Yes, that was my first thought as well. We have a number of conflicting objectives here: 1. Make it easy to find "OpenStack projects" (jeblair) 2. Reduce org management overhead and project renames (jeblair) 3. Be able to link programs with their associated repositories (ttx) 4. Be potentially able to define a set of projects that are "the OpenStack product" (markmc) > But then I thought that having lots > of orgs mostly just makes it harder for people to find projects, and we > should treat the openstack org as less of a name prefix (such as > "Openstack Nova") and more of a collection of OpenStack related > repositories. Since any program will, almost by definition, be working > on code related to OpenStack, it makes sense to put it in there. > > So this way we will end up with a smaller and simpler set of orgs (which > is less infrastructure overhead for us to manage), and it means that > people looking for a repo don't have to understand our project taxonomy > to know where to find it. Finally, this may mean fewer renames if our > taxonomy changes in the future. That's (1) and (2). Maybe we can address (3) and (4) in a way that doesn't involve the github orgs ? For (3) I think we could leverage a new field in projects.yaml that would let us associate a project with a program, letting us programatically find "all official projects" for ATC voting purposes, or answer the question "which program does this repo belong to". After all, those are not really end user questions, but rather taxonomists questions. For (4) I guess we could use a field too, but this is a bit inconvenient for end user discovery. Reducing the "openstack" org to projects that are cloud-infrastructure-related (and excluding the projects that help us achieve that goal) would make it clearer for end users to find our "key deliverables" and ignore the rest... To summarize, I think we can address my immediate taxonomy concerns without having to match github orgs and programs, but there may still be room for organizing orgs based on a "who consumes this" approach. But that can be solved over the long run. -- 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/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
On 26 June 2013 02:34, Mark McLoughlin wrote: > 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? So at the mission statement level we're focused on trunk today; if there are folk who would embrace stable branch delivery of TripleO I think we could certainly expand to have 'releases'. But, at the detailed level, we have a number of components - diskimage-builder, os-refresh-config, os-config-collector, os-apply-config, which are plumbing and should totally be consumed via releases. So the answer, I think is - from a 'released things' perspective we will contribute diskimage-builder releases, suitable for building images for any version of OpenStack, and a number of in-instance utilities that are designed to work well with Heat [and we're having a gentle long running conversation about whether Heat should own some of these]. And if there is significant interest in TripleO for not-trunk OpenStack, then we'll figure out how to integrate that into the TripleO process. -Rob -- Robert Collins 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
Thierry Carrez writes: > 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. Honestly, my first thought was "hey, we can have the orgs mirror the taxonomy, and that will be easy". But then I thought that having lots of orgs mostly just makes it harder for people to find projects, and we should treat the openstack org as less of a name prefix (such as "Openstack Nova") and more of a collection of OpenStack related repositories. Since any program will, almost by definition, be working on code related to OpenStack, it makes sense to put it in there. So this way we will end up with a smaller and simpler set of orgs (which is less infrastructure overhead for us to manage), and it means that people looking for a repo don't have to understand our project taxonomy to know where to find it. Finally, this may mean fewer renames if our taxonomy changes in the future. -Jim Plus it's currently sort of a mess anyway. ___ 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 Tue, 2013-06-25 at 18:58 +0200, Thierry Carrez wrote: > 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. Oslo follows the the same release cycle as the server projects, because they're part of the same "product" - the deliverables of Oslo don't have any (intended) use other than as part of the integrated release. They're not "borrowing" the same release cycle out of convenience, they're fundamentally part of the same development cycle. To take another example - say we split the Nova virt drivers out into separate projects with a well defined interface between them and Nova proper. They still should be part of the release. In this case, they'd still be in the Nova program, but it's the same idea - Oslo libraries are primarily just parts of the server projects split out and shared. > 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". I'm not trying to overload terms here - "integrated", "project", "program", etc. I need to parse and re-read your definitions of those because there's some subtleties in your think that surprise me ... and I'm not sure why all of these distinctions are so important. Your subtlety seems to be that only the server products are in the release and stuff like the OpenStack-producted libraries you need and the documentation to support it are some separate deliverable from the release? Is the distinction you're making that the only things in the release should be things which have gone through incubation? To my mind, the single most important thing we do is produce a software "product" (or "release", or "distribution") for people building clouds. I can't see how documentation, client libraries and supporting libraries aren't a fundamental part of that thing. > 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. I honestly don't really care much about ATC status in all of this. I'd be happy for that to be really broad - any sort of a contribution to anything officially part of the project. > 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... There are things we expect people to download from OpenStack and use to build a cloud. Producing that set of things is our main focus. There are things (i.e. clients) that we expect people to download from OpenStack and use to interact with OpenStack clouds. This is actually a subset of the above, because you can't build a cloud without these things. There are things which are critically important to helping us produce all of the above, but we don't expect cloud builders or cloud users to ever need them. Again, the first set of things and the target users (i.e. cloud builders) are the main reason we're here. I think we should be really clear about what's included in that set of things. My first question for any new program - and something I'd expect to see in their mission statement - is what things (if anything) the program will be contributing to the set of things that will be compelling for cloud builders. 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
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
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
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
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
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: > 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). +1 Cool, now the "Distribution/ReleaseManagement" program has one repo ! Even two, if I count the openstack-releasing tools :) That kinda proves that the "should have one repo" requirement doesn't really make sense for programs. -- 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 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
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 Tue, Jun 25, 2013 at 5:32 AM, Thierry Carrez wrote: > Sean Dague wrote: > > Does everything need to live under a program to get accounted for? > > Devstack isn't really a natural fit into the existing categories. Those > > of us that work on it tend to span a lot of categories anyway. I think > > as long as we acknowledge that it's an important project, and it's > > contributors will get counted as ATCs, where it fits in, or if it fits > > in to a program isn't all that important. > > Part of the rationale behind "programs" was to stop creating special > cases in the "official projects" list, and create some flexibility for > programs to add code repositories... So I would very much prefer if all > the contributions that grant ATC status fit somewhere in the taxonomy. > > Agreed with this and all of the discussion so far. > devstack could be its own program though, if the team caring for it is > really disjoint from Infrastructure and QA. > > I see DevStack under Infra and QA in its current role for the myriad projects. 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. Anne > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Anne Gentle annegen...@justwriteclick.com ___ 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 05:51 AM, Thierry Carrez wrote: > 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. > Yeah, sounds good to me. Just shorten the name ... "Release" or "Release Management". Stable branch maintenance and vulnerability management seem to fit well enough under that. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Programs
Sean Dague wrote: > Does everything need to live under a program to get accounted for? > Devstack isn't really a natural fit into the existing categories. Those > of us that work on it tend to span a lot of categories anyway. I think > as long as we acknowledge that it's an important project, and it's > contributors will get counted as ATCs, where it fits in, or if it fits > in to a program isn't all that important. Part of the rationale behind "programs" was to stop creating special cases in the "official projects" list, and create some flexibility for programs to add code repositories... So I would very much prefer if all the contributions that grant ATC status fit somewhere in the taxonomy. devstack could be its own program though, if the team caring for it is really disjoint from Infrastructure and QA. -- 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/24/2013 01:14 PM, Monty Taylor wrote: 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) Does everything need to live under a program to get accounted for? Devstack isn't really a natural fit into the existing categories. Those of us that work on it tend to span a lot of categories anyway. I think as long as we acknowledge that it's an important project, and it's contributors will get counted as ATCs, where it fits in, or if it fits in to a program isn't all that important. -Sean -- Sean Dague http://dague.net ___ 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
On 25 June 2013 20:19, Thierry Carrez 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 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: >> 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) > > Maybe Programs should have an incubation period, where they show they > have their s***^Wstuff together before being blessed ? I thought about that, but convinced myself that it wasn't really worth the extra bureaucracy. An incubation status is only useful if it gives you something that you wouldn't have if you grew the effort in isolation. In the case of incubated projects, it basically gives you release management attention (their releases end up being handled by me). It also gives you publicity so that programs and other projects start caring about you and integrate with you, so that you can safely be made part of the integrated release one day. Programs like Infrastructure, QA or Documentation all grew without the need to be incubated. They don't need release management attention, and they don't need as much integration publicity, since they are not bound to be part of the integrated release in the end. So I see the extra hassle of having to file for incubation, be accepted and then graduate... as not being worth it. We have loose teams informally gathering to work on stuff all the time. Let them just be. And if one day they think their work is critical to the success of the project and should be one of the project goals, they can apply to become an official program. >> * 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... > > If a Program has no code repos of it's own, but it's contributors > contribute to other projects, ATC status seems like a two-fold thing. > On the one hand, you want ATC status for individual contributors to > vote for the TC. Check, thats achieved. On the other hand you want ATC > status to vote for the PTL of the Program : that will be harder. As > Monty says, lets revisit. Also, I don't think we have any Program > 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. -- 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
Monty Taylor wrote:
> 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'.
It's worth noting that we already have an corner-case-handling procedure
in the TC charter to catch the improbable case of someone that would
have done bug/review work in the last year but not authored a single
patch. They can still apply for (and be granted) ATC status (see 'Voters
for TC seats ("ATC")' section).
>> * 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)
Makes sense under Infra, if their main contributors agree.
>> * Where would openstack/requirements fall ?
>
> I think openstack/requirements sits under oslo - although right now it's
> a joint-venture between oslo and infra.
Oslo++
--
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 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 24 June 2013 21:50, 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) Maybe Programs should have an incubation period, where they show they have their s***^Wstuff together before being blessed ? > * 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... If a Program has no code repos of it's own, but it's contributors contribute to other projects, ATC status seems like a two-fold thing. On the one hand, you want ATC status for individual contributors to vote for the TC. Check, thats achieved. On the other hand you want ATC status to vote for the PTL of the Program : that will be harder. As Monty says, lets revisit. Also, I don't think we have any Program 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. -Rob -- Robert Collins 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
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
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 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. > > 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
[openstack-dev] OpenStack Programs
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, and I'd like the programs mission statements to be precise rather than vague, so that the TC can bless them... * 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
