[openstack-dev] [Tripleo] Core reviewer update Dec

Ladislav Smola lsmola at redhat.com
Fri Dec 6 08:53:30 UTC 2013

On 12/05/2013 03:01 PM, James Slagle wrote:
> On Wed, Dec 4, 2013 at 2:10 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
>> On 5 December 2013 06:55, James Slagle <james.slagle at gmail.com> wrote:
>>> On Wed, Dec 4, 2013 at 2:12 AM, Robert Collins
>>>> Jan, Jordan, Martyn, Jiri and Jaromir are still actively contributing
>>>> to TripleO and OpenStack, but I don't think they are tracking /
>>>> engaging in the code review discussions enough to stay in -core: I'd
>>>> be delighted if they want to rejoin as core - as we discussed last
>>>> time, after a shorter than usual ramp up period if they get stuck in.
>>> What's the shorter than usual ramp up period?
>> You know, we haven't actually put numbers on it. But I'd be
>> comfortable with a few weeks of sustained involvement.
> +1.  Sounds reasonable.
>>> In general, I agree with your points about removing folks from core.
>>> We do have a situation though where some folks weren't reviewing as
>>> frequently when the Tuskar UI/API development slowed a bit post-merge.
>>>   Since that is getting ready to pick back up, my concern with removing
>>> this group of folks, is that it leaves less people on core who are
>>> deeply familiar with that code base.  Maybe that's ok, especially if
>>> the fast track process to get them back on core is reasonable.
>> Well, I don't think we want a situation where when a single org
>> decides to tackle something else for a bit, that noone can comfortably
>> fix bugs in e.g. Tuskar / or worse the whole thing stalls - thats why
>> I've been so keen to get /everyone/ in Tripleo-core familiar with the
>> entire collection of codebases we're maintaining.
>> So I think after 3 months that other cores should be reasonably familiar too ;).
> Well, it's not so much about just fixing bugs.  I'm confident our set
> of cores could fix bugs in almost any OpenStack related project, and
> in fact most do.  It was more just a comment around people who worked
> on the initial code being removed from core.  But, if others don't
> share that concern, and in fact Ladislav's comment about having
> confidence in the number of tuskar-ui guys still on core pretty much
> mitigates my concern :).

Well if it would be possible, I would rather keep guys who want to be 
more active in core. It's true that most of us worked on Horizon till 
now, preparing libraries we will need.
And in next couple months, we will be implementing that in Tuskar-UI. So 
having more core who understands that will be beneficial.

Basically me and tzumainn are working on Tuskar-UI fulltime. And ifarkas 
and tomas-8c8 are familiar enough with the code, but will be working on 
other projects. So that seems
to me like a minimal number of cores to keep us rolling(if nobody gets 
sick, etc.).

We will need to get patches in at certain cadence to keep the 
deadlines(patches will also depend on each other blocking other people), 
so in certain cases a +1 one from a non core
guy I have a confidence in, regarding e.g. deep knowledge of Angular.js 
or Horizon will be enough for me to approve the patch.

>> That said, perhaps we should review these projects.
>> Tuskar as an API to drive deployment and ops clearly belongs in
>> TripleO - though we need to keep pushing features out of it into more
>> generalised tools like Heat, Nova and Solum. TuskarUI though, as far
>> as I know all the other programs have their web UI in Horizon itself -
>> perhaps TuskarUI belongs in the Horizon program as a separate code
>> base for now, and merge them once Tuskar begins integration?
> IMO, I'd like to see Tuskar UI stay in tripleo for now, given that we
> are very focused on the deployment story.  And our reviewers are
> likely to have strong opinions on that :).  Not that we couldn't go
> review in Horizon if we wanted to, but I don't think we need the churn
> of making that change right now.
> So, I'll send my votes on the other folks after giving them a little
> more time to reply.
> Thanks.

More information about the OpenStack-dev mailing list