John Dickinson wrote: > On Jun 6, 2011, at 2:17 PM, Thierry Carrez wrote: >> The idea is to come up with a clear cost/benefit analysis and present it >> to the PPB which will estimate if the benefit outweighs the cost for the >> project. >> >> We already know from the design summit that developers seem to prefer >> the tool they are the most used to -- the question now is how costly it >> is to move. From the tools integration standpoint, but also other aspects. > > It seems that I misremembered. We (the swift team) were simply waiting for > the conversion tools to be done (which they are) and for us to have the time > to transition the code (which will happen soon).
Like Eric said, in order to make sure we're not changing only for a vocal minority, the PPB needs to vote. We don't want to set a precedent for vocal proponents of the next cool thing to force us to change again in 6 months. It's not just about branch conversion, since this is well understood. We need to have the rest of the continuous integration toolchain ready to work with git/github. I thought it was just a matter of mirroring the git trunk in LP and let Jenkins take it from there... But if it was that simple, I guess that would be ready for examination already. There is a cost, and it needs to be weighed against the benefit. If the cost in one week of work to get the tools aligned, the benefit certainly outweighs the cost. If it takes 6 man-months, it most certainly won't. Since reality is somewhere in between, the PPB needs to assess it. But first we need to know the cost :) > That being said, I am looking for a way for the swift devs to use the tools > of their choice (git/github in this case) and a way for the Openstack > organization to package and have visibility into the swift project. Having > gone through one round of a release now, I do see some great advantages for > Launchpad's packaging process. However, I would like to see swift moved to > github as soon as possible, probably with a Launchpad mirror of the code to > maintain the packaging advantages. Basically, I think that the packagers > should use their preferred tool (Launchpad) and the devs should use their > preferred tool (git). And for that matter, I'm a fan of independent projects > choosing their own dev tools as long as they have integration with the > packaging team. That's a separate subject (and one for the PPB as well): can an OpenStack core project choose its own code hosting ? Or should they all converge to a single platform ? I see John's point of letting devs use their tools of choice... but I also see that forces our developers to learn multiple tools if they want to work on "OpenStack" in general. Then what about issue management ? That's a user-facing tool, where uniformity between OpenStack core projects is even more desirable. Maybe that one should be added to the agenda for a future PPB session. -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
