Open Stack

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