Re: [openstack-dev] [TripleO] Can we create some subteams?

[John Trowbridge]

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?

[Jason Rist]

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?

[Ryan Brady]

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?

[Dan Prince]

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?

[Steven Hardy]

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?

[Steve Baker]

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?

[Jeremy Stanley]

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?

[Steve Baker]

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?

[Ben Nemec]

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?

[Dmitry Tantsur]

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?

[Steven Hardy]

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?

[Ben Nemec]

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?

[John Trowbridge]

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?

[Emilien Macchi]

+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?

[Jason Rist]

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?

[Steven Hardy]

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?

[John Trowbridge]

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