openstack-poc team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

John Dickinson wrote:

> 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.

Yes, that's what we need to discuss, and why I raised the subject for
PPB discussion. There are two conflicting views and we need something to
arbitrate, and PPB is the only body we have in absence of a BDFL.

> 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.

I agree that the GitHub code hosting limitations (especially the lack of
global merge request status and lack of support for complex acceptation
rules like the two-core-ack rule) mostly affect Nova, since Swift seems
to use a simpler one-core-review-suffices rule ?

If so, using LP branch mirrors for trunk and keeping milestone-proposed
on Launchpad is a great way to avoid disrupting the whole Swift release
process, as far as I'm concerned.

That said, you mention moving bugs and blueprints to github issues, and
*that* would be a lot more destructive (and we explicitly ruled out
bugs/blueprint migration for Diablo at the last design summit). So
please don't do it now :)

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack