Open Stack

On Fri, Jan 24, 2014 at 1:18 PM, Thierry Carrez <thierry at openstack.org>wrote:

> Jesse Noller wrote:
> > [...]
> > Given the schism in audiences, it looks like Horizon, this project, a
> unified CLI project and management of the individual CLI tools would fall
> under a Consumer / User Experience umbrella.
> >
> > If you look at the governance setup:
> >
> >       http://git.openstack.org/cgit/openstack/governance/commit/
> >
> > It seems to make sense that the UX proposal potentially be revived; but
> have actionable items under 3-4 sub teams:
> >
> > 1: Unified SDK / Consumer-Developer tools
> > 2: Unified Client tools (CLI)
> > 3: Horizon (UI)
> > 4: Security
> > 5: i18n
>
> A few remarks...
>
> I agree that the current CLI / developer experience is sub-optimal. From
> an organizational perspective, I think we can blame having the client
> libraries attached to each corresponding project's program, and having
> no clear home for the common client efforts.
>
> So I'd definitely welcome a team working on that, and would also
> definitely consider placing the existing client libraries under that
> umbrella if that group is willing to maintain them.
>
> But there are two key things to take into account.
>
> (1) Teams should exist first
> You can mandate anything you want, in the end if nobody is doing the
> work you won't get anywhere. That's why in OpenStack we took the view of
> letting teams spontaneously form rather than mandating that they exist,
> or rather then having them ask for permission first. A lot of people
> have been talking about CLI work in the past, but they never formed a
> team. The first step here is to gather the group of people interested in
> that topic and self-organize.
>
> (2) Teams scope should match what they work on
> There is no point in defining a scope if it doesn't match an existing
> team's focus. Yes, from an organizational perspective it makes sense to
> have Horizon and CLI folks in the same group, but if those end up being
> two separate subgroups working on those two sub-aspects, then two
> separate teams make a lot more sense.
>
> In summary, I'd really like we have a team working on unified CLI. But
> me saying it won't make it happen. A group of people working on that
> will make it happen. That group should form, self-organize, and start
> working on stuff. If the overlap between that team and another existing
> team is very large, then it will make sense for them to regroup. If not,
> they should exist as a separate team. Once that team starts producing
> outputs, it can apply to be recognized as an official program (which
> would make a lot of sense to me).
>

When it rains it pours.

I was speaking with Dean Troyer earlier today about putting together an
incubation request for an SDK program to hose the unified CLI (as a
scripting SDK) and client libraries (starting with python and expanding to
other languages later). There is already a group building the CLI (led by
Dean), and many of the people working on that are also interested in the
client libraries issue (along with many new contributors such as Jesse).
Since the CLI work is at a point where we think it's ready to be considered
for incubation, I suggested that Dean look into whether he would be able to
take the time to lead up the effort to create the program as part of
finding a proper home for the CLI. If he can't, we'll find someone else
from the group.

Doug


>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140124/491f0d18/attachment.html>