Re: [openstack-dev] [TripleO] Can we create some subteams?
On 04/11/2016 05:54 AM, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the other > informal subteams (tripleoclient, UI), and also add a new subteam for > tripleo-quickstart (and maybe one for releases?). > > We should make seperate ACL's for these subteams as well. The informal > approach of adding cores who can +2 anything but are told to only +2 > what they know doesn't scale very well. > > - trown > I went ahead and did this for tripleo-quickstart[1], and added Lars to the tripleo-quickstart core team. It is relatively painless for anyone else wanting to do the same. - trown [1] https://review.openstack.org/#/c/304145/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 04/13/2016 08:39 AM, Ryan Brady wrote: > On Mon, Apr 11, 2016 at 5:54 AM, John Trowbridge wrote: > > > Hola OOOers, > > > > It came up in the meeting last week that we could benefit from a CI > > subteam with its own meeting, since CI is taking up a lot of the main > > meeting time. > > > > I like this idea, and think we should do something similar for the other > > informal subteams (tripleoclient, UI), and also add a new subteam for > > tripleo-quickstart (and maybe one for releases?). > > > > We should make seperate ACL's for these subteams as well. The informal > > approach of adding cores who can +2 anything but are told to only +2 > > what they know doesn't scale very well. > > > > +1 to subteams for selected projects. > > I think there should be a clearly defined practice of ensuring there is > enough reviewers so that a subteam core doesn't need to +A their own > patches. I don't know if that's a standing rule in tripleo core, but I > think it should be explicit in subteams. > > -r > Another +1 to this. -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On Mon, Apr 11, 2016 at 5:54 AM, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the other > informal subteams (tripleoclient, UI), and also add a new subteam for > tripleo-quickstart (and maybe one for releases?). > > We should make seperate ACL's for these subteams as well. The informal > approach of adding cores who can +2 anything but are told to only +2 > what they know doesn't scale very well. > +1 to subteams for selected projects. I think there should be a clearly defined practice of ensuring there is enough reviewers so that a subteam core doesn't need to +A their own patches. I don't know if that's a standing rule in tripleo core, but I think it should be explicit in subteams. -r > - trown > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On Mon, 2016-04-11 at 05:54 -0400, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the > other > informal subteams (tripleoclient, UI), and also add a new subteam for > tripleo-quickstart (and maybe one for releases?). > > We should make seperate ACL's for these subteams as well. The > informal > approach of adding cores who can +2 anything but are told to only +2 > what they know doesn't scale very well. +1 for some subteams. I think they make good sense for projects which are adopted upstream into projects like TripleO. I wouldn't say we have to go crazy and do it for everything but for projects like quickstart it seems fine to me. Dan > > - trown > > _ > _ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On Tue, Apr 12, 2016 at 12:01:39PM +1200, Steve Baker wrote: >On 12/04/16 11:48, Jeremy Stanley wrote: > > On 2016-04-12 11:43:06 +1200 (+1200), Steve Baker wrote: > > Can I suggest a sub-team for > os-collect-config/os-refresh-config/os-apply-config? I ask since > these tools also make up the default heat agent, and there is > nothing in them which is TripleO specific. > > Could make sense similarly for diskimage-builder, as there is a lot > of TripleO/Infra cross-over use and contribution happening there. > >+1, this tool is general purpose and has diverse contributors and >consumers This already exists: https://review.openstack.org/#/admin/groups/115,members https://github.com/openstack-infra/project-config/blob/master/gerrit/acls/openstack/diskimage-builder.config It's already in use and a number of folks not (or no longer) active in tripleo-core have been added as they are involved with DiB. There is also already a sub-team for os-apply-config but it currently only contains tripleo-core: https://github.com/openstack-infra/project-config/blob/master/gerrit/acls/openstack/os-apply-config.config https://review.openstack.org/#/admin/groups/142,members For os-*-config I'm not sure we gain much as the contribution rate is pretty low - like there's maybe one or two outstanding patches right now accross all three projects. Thus it could be argued that there's little justification for actively managing a sub-team in that case. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 12/04/16 11:48, Jeremy Stanley wrote: On 2016-04-12 11:43:06 +1200 (+1200), Steve Baker wrote: Can I suggest a sub-team for os-collect-config/os-refresh-config/os-apply-config? I ask since these tools also make up the default heat agent, and there is nothing in them which is TripleO specific. Could make sense similarly for diskimage-builder, as there is a lot of TripleO/Infra cross-over use and contribution happening there. +1, this tool is general purpose and has diverse contributors and consumers __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 2016-04-12 11:43:06 +1200 (+1200), Steve Baker wrote: > Can I suggest a sub-team for > os-collect-config/os-refresh-config/os-apply-config? I ask since > these tools also make up the default heat agent, and there is > nothing in them which is TripleO specific. Could make sense similarly for diskimage-builder, as there is a lot of TripleO/Infra cross-over use and contribution happening there. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 11/04/16 22:19, Steven Hardy wrote: On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: Hola OOOers, It came up in the meeting last week that we could benefit from a CI subteam with its own meeting, since CI is taking up a lot of the main meeting time. I like this idea, and think we should do something similar for the other informal subteams (tripleoclient, UI), and also add a new subteam for tripleo-quickstart (and maybe one for releases?). +1, from the meeting and other recent discussions it sounds like defining some sub-teams would be helpful, let's try to enumerate those discussed: - tripleo-ci - API (Mistral based API which is landing in tripleo-common atm) - Tripleo-UI - os-net-config - python-tripleoclient - tripleo-quickstart Can I suggest a sub-team for os-collect-config/os-refresh-config/os-apply-config? I ask since these tools also make up the default heat agent, and there is nothing in them which is TripleO specific. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 04/11/2016 12:12 PM, Steven Hardy wrote: > On Mon, Apr 11, 2016 at 10:33:53AM -0500, Ben Nemec wrote: >> On 04/11/2016 04:54 AM, John Trowbridge wrote: >>> Hola OOOers, >>> >>> It came up in the meeting last week that we could benefit from a CI >>> subteam with its own meeting, since CI is taking up a lot of the main >>> meeting time. >>> >>> I like this idea, and think we should do something similar for the other >>> informal subteams (tripleoclient, UI), and also add a new subteam for >>> tripleo-quickstart (and maybe one for releases?). >>> >>> We should make seperate ACL's for these subteams as well. The informal >>> approach of adding cores who can +2 anything but are told to only +2 >>> what they know doesn't scale very well. >> >> How so? Are we planning to give people +2 even though we don't trust >> them to not +2 things they shouldn't? I remain of the opinion that if >> we need ACL controls to keep someone from doing something then they >> shouldn't have +2 in the first place. > > IMO it's not about a lack of trust at all, there are several other projects > using this model and there are a number of advantages: > > - Clear responsibilities enable better communication, e.g having a clearly > defined core team for a specific subteam enables folks to more easily > know the folks they should approach re reviews, to discuss features etc. Fair enough, although I'm not sure a wiki page wouldn't be a better way to capture this information. We're never going to have granular enough gerrit groups to capture things like who the experts on upgrades/networking/ssl/etc. are. > > - Beyond a certain point, large teams make disscussion e.g in a timeboxed > weekly meeting hard. We're already at this point, e.g folks show up > wanting to add an item to the weekly agenda on some topic, but we spend > 59 of the available 60 minutes discussing bugs, specs and CI. Having > sub-teams that feel empowered to self-organize e.g extra meetings and > their own core members may help this process scale a little better? I probably should have been more explicit that I'm only referring to separate Gerrit groups. Totally +1 on the concept of sub-teams in general. > > - Potentially easier on-ramp (encourage domain experts as sub-team cores), > this isn't about lack of trust, it's acknowledging that spending a year > or more learning all the different pieces of TripleO is really hard and > not everyone wants or needs to do it. Would folks feel a little more > motivated to contribute if they could aim towards deep expertise > reviewing a smaller subsystem? > >> Quickstart is a bit of a weird case because the regular contributors to >> it have not previously been very involved in TripleO upstream so I don't >> think most of us have enough context to know whether they should have >> +2. I guess the UI would fall under the same category, so I'd be in >> favor of keeping those two separate, but otherwise I think we're >> creating bureaucracy for its own sake. > > I think the overhead of creating a few additional gerrit groups is pretty > small, there's zero "bureaucracy" for pretty much everyone involved, > tripleo-core still works the same but we might just be a little quicker to > nominate folks and/or attract reviews on some smaller projects given this > change IMO (again, not through any lack of trust but because the teams > would better represent the way folks are actually working). I still have reservations, but once again I seem to be in the minority here so I won't spend a lot of time arguing the point. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 04/11/2016 05:33 PM, Ben Nemec wrote: On 04/11/2016 04:54 AM, John Trowbridge wrote: Hola OOOers, It came up in the meeting last week that we could benefit from a CI subteam with its own meeting, since CI is taking up a lot of the main meeting time. I like this idea, and think we should do something similar for the other informal subteams (tripleoclient, UI), and also add a new subteam for tripleo-quickstart (and maybe one for releases?). We should make seperate ACL's for these subteams as well. The informal approach of adding cores who can +2 anything but are told to only +2 what they know doesn't scale very well. How so? Are we planning to give people +2 even though we don't trust them to not +2 things they shouldn't? I remain of the opinion that if we need ACL controls to keep someone from doing something then they shouldn't have +2 in the first place. Quickstart is a bit of a weird case because the regular contributors to it have not previously been very involved in TripleO upstream so I don't think most of us have enough context to know whether they should have +2. I guess the UI would fall under the same category, so I'd be in favor of keeping those two separate, but otherwise I think we're creating bureaucracy for its own sake. FWIW it works pretty well for the ironic-inspector-core subteam of the big ironic-core. -Ben __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On Mon, Apr 11, 2016 at 10:33:53AM -0500, Ben Nemec wrote: > On 04/11/2016 04:54 AM, John Trowbridge wrote: > > Hola OOOers, > > > > It came up in the meeting last week that we could benefit from a CI > > subteam with its own meeting, since CI is taking up a lot of the main > > meeting time. > > > > I like this idea, and think we should do something similar for the other > > informal subteams (tripleoclient, UI), and also add a new subteam for > > tripleo-quickstart (and maybe one for releases?). > > > > We should make seperate ACL's for these subteams as well. The informal > > approach of adding cores who can +2 anything but are told to only +2 > > what they know doesn't scale very well. > > How so? Are we planning to give people +2 even though we don't trust > them to not +2 things they shouldn't? I remain of the opinion that if > we need ACL controls to keep someone from doing something then they > shouldn't have +2 in the first place. IMO it's not about a lack of trust at all, there are several other projects using this model and there are a number of advantages: - Clear responsibilities enable better communication, e.g having a clearly defined core team for a specific subteam enables folks to more easily know the folks they should approach re reviews, to discuss features etc. - Beyond a certain point, large teams make disscussion e.g in a timeboxed weekly meeting hard. We're already at this point, e.g folks show up wanting to add an item to the weekly agenda on some topic, but we spend 59 of the available 60 minutes discussing bugs, specs and CI. Having sub-teams that feel empowered to self-organize e.g extra meetings and their own core members may help this process scale a little better? - Potentially easier on-ramp (encourage domain experts as sub-team cores), this isn't about lack of trust, it's acknowledging that spending a year or more learning all the different pieces of TripleO is really hard and not everyone wants or needs to do it. Would folks feel a little more motivated to contribute if they could aim towards deep expertise reviewing a smaller subsystem? > Quickstart is a bit of a weird case because the regular contributors to > it have not previously been very involved in TripleO upstream so I don't > think most of us have enough context to know whether they should have > +2. I guess the UI would fall under the same category, so I'd be in > favor of keeping those two separate, but otherwise I think we're > creating bureaucracy for its own sake. I think the overhead of creating a few additional gerrit groups is pretty small, there's zero "bureaucracy" for pretty much everyone involved, tripleo-core still works the same but we might just be a little quicker to nominate folks and/or attract reviews on some smaller projects given this change IMO (again, not through any lack of trust but because the teams would better represent the way folks are actually working). Cheers, Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 04/11/2016 04:54 AM, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the other > informal subteams (tripleoclient, UI), and also add a new subteam for > tripleo-quickstart (and maybe one for releases?). > > We should make seperate ACL's for these subteams as well. The informal > approach of adding cores who can +2 anything but are told to only +2 > what they know doesn't scale very well. How so? Are we planning to give people +2 even though we don't trust them to not +2 things they shouldn't? I remain of the opinion that if we need ACL controls to keep someone from doing something then they shouldn't have +2 in the first place. Quickstart is a bit of a weird case because the regular contributors to it have not previously been very involved in TripleO upstream so I don't think most of us have enough context to know whether they should have +2. I guess the UI would fall under the same category, so I'd be in favor of keeping those two separate, but otherwise I think we're creating bureaucracy for its own sake. -Ben __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 04/11/2016 06:19 AM, Steven Hardy wrote: > On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: >> Hola OOOers, >> >> It came up in the meeting last week that we could benefit from a CI >> subteam with its own meeting, since CI is taking up a lot of the main >> meeting time. >> >> I like this idea, and think we should do something similar for the other >> informal subteams (tripleoclient, UI), and also add a new subteam for >> tripleo-quickstart (and maybe one for releases?). > > +1, from the meeting and other recent discussions it sounds like defining > some sub-teams would be helpful, let's try to enumerate those discussed: > > - tripleo-ci > - API (Mistral based API which is landing in tripleo-common atm) > - Tripleo-UI > - os-net-config > - python-tripleoclient > - tripleo-quickstart > > Of these, I think tripleo-ci, tripleo-ui, os-net-config and > tripleo-quickstart all make sense to create sub-teams. > > However it's less clear if we should create separate teams for > tripleoclient and the API - IMO everyone should care about the CLI flow, so > it'd be good to encourage broader participation there, but if there's > consensus we can add that. > > In the API case it's tough because it's being proposed to tripleo-common, > so it'll be difficult to have an ACL which only affects the location of the > API code. Also it's another key interface where we probably want to really > encourage broad participation in review/development - currently there's a > small team working on the API implementation but I really hope that changes > when we move the Mistral based API to be in the default deployment flow. > For gerrit ACLs, I was thinking the main tripleo-core group would have core on all of the subteams, and the subteam groups would be just for adding folks who only have "limited" core responsibilities/privileges. If we have more strictly limited subteams though, I agree that CLI and API should probably not be split out. If we do split out API, I think the ACL being on the whole tripleo-common repo is fine. There is not a ton of non-API related stuff in tripleo-common anyways. > Regarding releases, there actually already is a tripleo-release group, but > I'm not sure we want to maintain that model long-term, instead we should be > moving towards the common openstack/releases tooling ref: > > http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html > > Improving our release workflow and figuring out how we align/integrate > better with the OpenStack coordinated/centralized release is high on my > TODO list as PTL for Newton, and it's definitely something I'm keen to > discuss further e.g at summit (and get help with! :) > >> We should make seperate ACL's for these subteams as well. The informal >> approach of adding cores who can +2 anything but are told to only +2 >> what they know doesn't scale very well. > > Agreed, there's definitely value in doing this now and it will provide more > value as our community grows. > > Steve > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
+1 from me too, we have it in Puppet OpenStack group, and it works just fine. On Mon, Apr 11, 2016 at 10:27 AM, Jason Rist wrote: > On 04/11/2016 04:19 AM, Steven Hardy wrote: >> On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: >> > Hola OOOers, >> > >> > It came up in the meeting last week that we could benefit from a CI >> > subteam with its own meeting, since CI is taking up a lot of the main >> > meeting time. >> > >> > I like this idea, and think we should do something similar for the other >> > informal subteams (tripleoclient, UI), and also add a new subteam for >> > tripleo-quickstart (and maybe one for releases?). >> >> +1, from the meeting and other recent discussions it sounds like defining >> some sub-teams would be helpful, let's try to enumerate those discussed: >> >> - tripleo-ci >> - API (Mistral based API which is landing in tripleo-common atm) >> - Tripleo-UI >> - os-net-config >> - python-tripleoclient >> - tripleo-quickstart >> >> Of these, I think tripleo-ci, tripleo-ui, os-net-config and >> tripleo-quickstart all make sense to create sub-teams. >> >> However it's less clear if we should create separate teams for >> tripleoclient and the API - IMO everyone should care about the CLI flow, so >> it'd be good to encourage broader participation there, but if there's >> consensus we can add that. >> >> In the API case it's tough because it's being proposed to tripleo-common, >> so it'll be difficult to have an ACL which only affects the location of the >> API code. Also it's another key interface where we probably want to really >> encourage broad participation in review/development - currently there's a >> small team working on the API implementation but I really hope that changes >> when we move the Mistral based API to be in the default deployment flow. >> >> Regarding releases, there actually already is a tripleo-release group, but >> I'm not sure we want to maintain that model long-term, instead we should be >> moving towards the common openstack/releases tooling ref: >> >> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html >> >> Improving our release workflow and figuring out how we align/integrate >> better with the OpenStack coordinated/centralized release is high on my >> TODO list as PTL for Newton, and it's definitely something I'm keen to >> discuss further e.g at summit (and get help with! :) >> >> > We should make seperate ACL's for these subteams as well. The informal >> > approach of adding cores who can +2 anything but are told to only +2 >> > what they know doesn't scale very well. >> >> Agreed, there's definitely value in doing this now and it will provide more >> value as our community grows. >> >> Steve >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > Very big +1 to this. I feel like it will help speed up the dev process. > > -- > Jason E. Rist > Senior Software Engineer > OpenStack User Interfaces > Red Hat, Inc. > openuc: +1.972.707.6408 > mobile: +1.720.256.3933 > Freenode: jrist > github/twitter: knowncitizen > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On 04/11/2016 04:19 AM, Steven Hardy wrote: > On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: > > Hola OOOers, > > > > It came up in the meeting last week that we could benefit from a CI > > subteam with its own meeting, since CI is taking up a lot of the main > > meeting time. > > > > I like this idea, and think we should do something similar for the other > > informal subteams (tripleoclient, UI), and also add a new subteam for > > tripleo-quickstart (and maybe one for releases?). > > +1, from the meeting and other recent discussions it sounds like defining > some sub-teams would be helpful, let's try to enumerate those discussed: > > - tripleo-ci > - API (Mistral based API which is landing in tripleo-common atm) > - Tripleo-UI > - os-net-config > - python-tripleoclient > - tripleo-quickstart > > Of these, I think tripleo-ci, tripleo-ui, os-net-config and > tripleo-quickstart all make sense to create sub-teams. > > However it's less clear if we should create separate teams for > tripleoclient and the API - IMO everyone should care about the CLI flow, so > it'd be good to encourage broader participation there, but if there's > consensus we can add that. > > In the API case it's tough because it's being proposed to tripleo-common, > so it'll be difficult to have an ACL which only affects the location of the > API code. Also it's another key interface where we probably want to really > encourage broad participation in review/development - currently there's a > small team working on the API implementation but I really hope that changes > when we move the Mistral based API to be in the default deployment flow. > > Regarding releases, there actually already is a tripleo-release group, but > I'm not sure we want to maintain that model long-term, instead we should be > moving towards the common openstack/releases tooling ref: > > http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html > > Improving our release workflow and figuring out how we align/integrate > better with the OpenStack coordinated/centralized release is high on my > TODO list as PTL for Newton, and it's definitely something I'm keen to > discuss further e.g at summit (and get help with! :) > > > We should make seperate ACL's for these subteams as well. The informal > > approach of adding cores who can +2 anything but are told to only +2 > > what they know doesn't scale very well. > > Agreed, there's definitely value in doing this now and it will provide more > value as our community grows. > > Steve > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Very big +1 to this. I feel like it will help speed up the dev process. -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Can we create some subteams?
On Mon, Apr 11, 2016 at 05:54:11AM -0400, John Trowbridge wrote: > Hola OOOers, > > It came up in the meeting last week that we could benefit from a CI > subteam with its own meeting, since CI is taking up a lot of the main > meeting time. > > I like this idea, and think we should do something similar for the other > informal subteams (tripleoclient, UI), and also add a new subteam for > tripleo-quickstart (and maybe one for releases?). +1, from the meeting and other recent discussions it sounds like defining some sub-teams would be helpful, let's try to enumerate those discussed: - tripleo-ci - API (Mistral based API which is landing in tripleo-common atm) - Tripleo-UI - os-net-config - python-tripleoclient - tripleo-quickstart Of these, I think tripleo-ci, tripleo-ui, os-net-config and tripleo-quickstart all make sense to create sub-teams. However it's less clear if we should create separate teams for tripleoclient and the API - IMO everyone should care about the CLI flow, so it'd be good to encourage broader participation there, but if there's consensus we can add that. In the API case it's tough because it's being proposed to tripleo-common, so it'll be difficult to have an ACL which only affects the location of the API code. Also it's another key interface where we probably want to really encourage broad participation in review/development - currently there's a small team working on the API implementation but I really hope that changes when we move the Mistral based API to be in the default deployment flow. Regarding releases, there actually already is a tripleo-release group, but I'm not sure we want to maintain that model long-term, instead we should be moving towards the common openstack/releases tooling ref: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html Improving our release workflow and figuring out how we align/integrate better with the OpenStack coordinated/centralized release is high on my TODO list as PTL for Newton, and it's definitely something I'm keen to discuss further e.g at summit (and get help with! :) > We should make seperate ACL's for these subteams as well. The informal > approach of adding cores who can +2 anything but are told to only +2 > what they know doesn't scale very well. Agreed, there's definitely value in doing this now and it will provide more value as our community grows. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Can we create some subteams?
Hola OOOers, It came up in the meeting last week that we could benefit from a CI subteam with its own meeting, since CI is taking up a lot of the main meeting time. I like this idea, and think we should do something similar for the other informal subteams (tripleoclient, UI), and also add a new subteam for tripleo-quickstart (and maybe one for releases?). We should make seperate ACL's for these subteams as well. The informal approach of adding cores who can +2 anything but are told to only +2 what they know doesn't scale very well. - trown __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev