openstack-poc team mailing list archive

[John Dickinson <john.dickinson@xxxxxxxxxxxxx>]

On Jun 20, 2011, at 8:10 PM, Jay Pipes wrote:

> While Andy Smith has documented how to migrate
> (everything) over to GitHub, there are known issues around pull
> requests not having a granular enough status to work with our
> automated patch queue management and review process. While it may be
> fine for Swift, where there are far fewer developers, bugs and
> blueprints, for Nova, we can't risk doing a move without fully
> thinking out the plan and paying attention to all the details.

This is the crux of the issue, I believe. You seem to imply that there should be one dev process for all openstack projects. I disagree. The projects have different devs and are in different stages of maturity. Requiring uniformity in dev process also does not make sense when new openstack projects are considered. As a reference point, note that both project currently being discussed for inclusion do things differently (scalr using google code but soon to move to github and the dashboard already using github for code). Most other "affiliated" projects are also doing things differently than either swift or nova or glance.

If the swift devs (or the devs for any other project) can maintain a high degree of effectiveness while using differing dev toolsets, so be it. Let them choose the tools they use for their own work. This is the issue of "pressing importance" that needs to be addressed: What are the requirements that the PPB place on the dev workflow for the individual core projects? Are there, in fact, any "individual" projects or only one "openstack" project? These questions get to the root of most of the larger openstack discussions that have occurred so far (eg versioning, branching model, code hosting, and release schedules). Most of the decisions that have been made so far seem to point in the direction of projects with a high degree of autonomy.

All of the swift developers want to move the code to git/github. We would like to make this move as soon as possible, but the more general issue is the extent of project autonomy. Solve this and most of the other questions go away.

We want to do what we can to encourage the openstack project as a whole. Frankly, we expected something to have happened by now relating to the github migration, but since it hasn't, we want to lead the charge forward and address issues relating to using github for others who also choose to use github.

On a more practical level, I think that those most affected by a project using code hosting or issue tracking other than launchpad are those involved in the openstack packaging (namely, Thierry). The issues surrounding a particular code hoster's features (eg githubs granularity on pull requests) either have solutions or are easily solvable. I think the biggest practical question around code hosting is figuring out how the openstack packagers can easily get good copies of the right code to use in an official release.

--John

Attachment: smime.p7s
Description: S/MIME cryptographic signature