Open Stack

Hi Brandon,

Yep, that sounds like a good way to approach this. And FWIW, this week I'm
planning on moving several of the designs I've presented to the group into
blueprints / gerrit specs for the project and otherwise start working on a
roadmap to actually get the thing built.

In the mean time, there's still a ton that needs to be done on the Neutron
LBaaS side of things to make sure we get feature improvements and cleaner
Neutron API interfaces in before the Juno freeze. So I don't think there's
a reason anyone should be idle working on these two projects, eh.

Stephen


On Sun, Jun 22, 2014 at 11:38 AM, Brandon Logan <brandon.logan at rackspace.com
> wrote:

> I'm thinking we are going to need more than 2 on the core team at first
> but it is hard to tell exactly how many people will be contributing code
> at first.  I know we've got a lot of interested parties and the
> possibility that some 10+ people are actively contributing.  Of course,
> these things can only be predicted and will be unknown until it is
> actually known.
>
> Also, we really need to have a good plan of action.  Once we get a
> consensus on the design we should start breaking the implementation up
> into umbrella blueprint specs (or epic blueprint specs) with each one
> detailing the bigger picture and breaking up the bigger picture into
> smaller tasks/stories that can be accomplished.  Then people can start
> choosing which they would like to implement.  Sounds good in theory, but
> actually executing it will be the tough part.
>
> Thanks,
> Brandon
>
> On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote:
> > On 20/06/14 07:29 +0100, Mark McLoughlin wrote:
> > >On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:
> > >> Dolph,
> > >>
> > >>
> > >> I appreciate the suggestion. In the mean time how does the review
> > >> process work without core developers to approve gerrit submissions?
> > >
> > >If you're just getting started, have a small number (possibly just 1 to
> > >begin with) of developers collaborate closely, with the minimum possible
> > >process and then use that list of developers as your core review team
> > >when you gradually start adopting some process. Aim to get from zero to
> > >bootstrapped with that core team in a small number of weeks at most.
> > >
> > >Minimum possible process could mean a git repo anywhere that those
> > >initial developers have direct push access to. You could use stackforge
> > >from the beginning and the developers just approve their own changes,
> > >but that's a bit annoying.
> >
> > +1 this is how we did it in Marconi (except for the repo with push
> > access). At the beginning, we kept a core team of 2 developers despite
> > there being at least 4 ppl working on the project. This allowed the
> > team to have better discussions on what got in the repo and what not.
> >
> > One benefit of using stackforge is that you get a great CI system to
> > test your project with but the development will slow down for sure. We
> > started on stackforge right away, then had a 2 days hackathon on a
> > github fork which was not a good idea because we had to submit al
> > those patches for review after the hackathon. :(
> >
> > Flavio
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140622/2c7401a3/attachment.html>