Open Stack

While I agree with most of what Thierry said, I need clarifications though,
on what a Program is, and what is the key point where an idea should get
its own Program instead of being headed by an already existing Program.

For example, take Barbican which is providing extra features to Keystone,
or Docker which will provide its own API for managing VMs. Are they both
eligible for new Programs, or should they stick to the existing programs
(respectively Identity and Compute) ?

If the answer is "they can be part of the already existing Programs", then
how can we leverage the difference in between the projects (ie. Keystone is
Openstack, Barbican is Stackforge), and how could at some point the code
getting incubated ?

That said, Climate (Reservations as a Service) does have the same concern,
while we're not yet planning to ask for incubation until a certain point,
which needs to be discussed internally.

Thanks,
-Sylvain




2013/12/13 Russell Bryant <rbryant at redhat.com>

> On 12/13/2013 10:37 AM, Flavio Percoco wrote:
> > On 13/12/13 15:53 +0100, Thierry Carrez wrote:
> >> Hi everyone,
> >>
> >> TL;DR: Incubation is getting harder, why not ask efforts to apply
> >> for a new program first to get the visibility they need to grow.
> >>
> >> Long version:
> >>
> >> Last cycle we introduced the concept of "Programs" to replace
> >> the concept of "Official projects" which was no longer working
> >> that well for us. This was recognizing the work of existing
> >> teams, organized around a common mission, as an integral part of
> >> "delivering OpenStack". Contributors to programs become ATCs, so
> >> they get to vote in Technical Committee (TC) elections. In
> >> return, those teams place themselves under the authority of the
> >> TC.
> >>
> >> This created an interesting corner case. Projects applying for
> >> incubation would actually request two concurrent things: be
> >> considered a new "Program", and give "incubated" status to a code
> >> repository under that program.
> >>
> >> Over the last months we significantly raised the bar for
> >> accepting new projects in incubation, learning from past
> >> integration and QA mistakes. The end result is that a number of
> >> promising projects applied for incubation but got rejected on
> >> maturity, team size, team diversity, or current integration level
> >> grounds.
> >>
> >> At that point I called for some specific label, like "Emerging
> >> Technology" that the TC could grant to promising projects that
> >> just need more visibility, more collaboration, more
> >> crystallization before they can make good candidates to be made
> >> part of our integrated releases.
> >>
> >> However, at the last TC meeting it became apparent we could
> >> leverage "Programs" to achieve the same result. Promising efforts
> >> would first get their mission, scope and existing results blessed
> >> and recognized as something we'd really like to see in OpenStack
> >> one day. Then when they are ready, they could have one of their
> >> deliveries apply for incubation if that makes sense.
> >>
> >> The consequences would be that the effort would place itself
> >> under the authority of the TC. Their contributors would be ATCs
> >> and would vote in TC elections, even if their deliveries never
> >> make it to incubation. They would get (some) space at Design
> >> Summits. So it's not "free", we still need to be pretty
> >> conservative about accepting them, but it's probably manageable.
> >>
> >> I'm still weighing the consequences, but I think it's globally
> >> nicer than introducing another status. As long as the TC feels
> >> free to revoke Programs that do not deliver the expected results
> >> (or that no longer make sense in the new world order) I think
> >> this approach would be fine.
> >>
> >> Comments, thoughts ?
> >>
> >
> >
> > My first thought while reading this email was:
> >
> > What happens if that "Emerging Technology" doesn't move forward?
>
> Thierry addressed that at the very end of his message:
>
>   As long as the TC feels free to revoke  Programs that do not deliver
>   the expected results (or that no longer make sense in the new world
>   order) I think this approach would be fine.
>
> > Will a Program with actual projects exist? (I personally think
> > this will create some confusion).
> >
> > I guess the same thing would happen with incubated projects that
> > never graduate to integrated. However, the probability this would
> > happen are way lower. You also make a good point w.r.t ATCs and the
> > rights to vote.
> >
> > -1 from me. I'd be even in favor to not calling any Program
> > official until there's an integrated *team* - not project - working
> > on it. Notice that I'm using the term 'team' and not projects.
> > Programs like 'Documentation' have an integrated team working on it
> > and are part of every release cycle, the same thing applies for the
> > "Release Cycle Management" program, etc.
>
> We wouldn't create a program without an existing team doing some work
> already.  We even have rules around now programs along side the rules
> for incubating/graduating projects:
>
>
> http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements
>
> > With the above, I'm basically saying that a Queuing ;) program
> > shouldn't exist until there's an integrated team of folks working
> > on queuing. Incubation doesn't guarantees integration and
> > "emerging technology" doesn't guarantees incubation. Both stages
> > mean there's interest about that technology and that we're looking
> > forward to see it being part of OpenStack, period. Each stage
> > probably means a bit more than that but, IMHO, that's the
> > 'community' point of view of those stages.
> >
> > What if we have a TC-managed* Program incubation period? The
> > Program won't be managed by the team working on the emerging
> > technology, nor the team working on the incubated project. Until
> > those projects don't graduate, the program won't be official nor
> > will have the 'rights' of other programs. And if the project fits
> > into another program, then it won't be officially part of it until
> > it graduates.
> >
> > Unless I'm completely wrong about what a program is / should be,
> > I'm leaning towards -1.
> >
> > * I'm sorry, I couldn't come up with a better term for this. :)
> >
> > Cheers, FF
> >
> >
> >
> >
> > _______________________________________________ OpenStack-dev
> > mailing list OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131213/74bf6ac4/attachment.html>