openstack-poc team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Mon, Jun 20, 2011 at 11:44 PM, John Dickinson
<john.dickinson@xxxxxxxxxxxxx> wrote:
>
> 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.

This reflects the Swift worldview. However, there are multiple teams
(Canonical, Citrix, Cisco, to name a few) that neither prefer GitHub
nor are looking forward to retraining their devs on GitHub. Moving
bugs, blueprints, and changing the code review process is a major
hurdle, and is one of the reasons why we are advocating a staged
migration.

Having bugs and blueprints for all core OpenStack projects on a single
platform is a valuable thing. It enables sysadmins, project managers,
and others interested in deploying OpenStack as a holistic set of
components to find out, in a single place:

a) What's currently in the components
b) What known issues are with the components
c) What the plans are for the components in the future

If we allow every project to have a separate bug tracker, milestone
management and development process, visibility into OpenStack -- the
holistic set of components -- is made very difficult. It is the job of
the PPB to ensure that the OpenStack brand and projects expose a
cohesive set of design principles, interrelated functionality, and
unified sense of direction in relation to each other. While it is your
job to push for the things that you and your team prefer -- and I
understand your preference completely -- it is the job of the PPB to
guide the OpenStack project as a whole, and I ask you to put on your
non-Swift hat for a moment and consider the dilemma faced by a
potential user of not just Swift, but OpenStack, including Swift.

Cheers,
jay