openstack-poc team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

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