osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PowerVMStackers][Winstackers][uc][tc] Encourage to transform from project to SIG


William M Edmonds - edmondsw at us.ibm.com wrote:
> [...]
>> 3. Any concerns or objections on moving from project to SIG?
> 
> Lots...
> 
> I can see why, at a quick glance, one might think that PowerVMStackers is like a special interest group. The name would certainly imply that. But that's out of historical necessity rather than what's proper. It's really not much like a SIG in what it does.
> 
> The three projects that PowerVMStackers contains (nova-powervm, networking-powervm, and ceilometer-powervm) are drivers/agents for nova, neutron, and ceilometer. They should ideally be under the umbrella of those projects, as other drivers/agents are, rather than split out as a PowerVMStackers project or SIG. But sadly, that is not the case due to historical reasons (primarily, the nova cores would not allow the nova powervm driver to be developed within nova like the drivers for Hyper-V, VMware, etc. so we had to create nova-powervm separately to do that development). I assure you that I've never liked that false dichotomy, but it was not our choice. The right thing to do here is to get them under those umbrellas, not to convert PowerVMStackers to a SIG. They need to be developed and managed just like any other OpenStack project producing code... not a SIG.

SIGs can produce code. The difference with project teams is that our 
project teams are organized around a specific component (Nova, Swift...) 
or a horizontal software development function that applies to all those 
components (QA, Documentation, release management, common libraries...)

Once you frame it like that, you can spot a few outliers in the current 
project team list: things that are neither centered around a specific 
component nor a horizontal function: PowerVMStackers and Winstackers.

That said, I understand your objection. Establishing PowerVMStackers as 
a SIG clearly sends the message that caring about PowerVM is a special 
interest and not everyone's interest. It makes it less likely that the 
*-powervm repository/features ever get merged into their respective 
projects. And if this merging is right around the corner, I agree that 
setting up a PowerVM SIG is counterproductive.

So I guess the real question is, is PowerVM support a mainline feature 
that just happens to be temporarily maintained under a specific team for 
weird organizational reasons ? Or is it considered not to be mainline 
material (a bit like Windows support), and therefore the people that 
care about that feature should maintain code to support that 
indefinitely on the side ?

If it's the former, and there is a clear plan to get all that 
functionality up in their respective teams in a near future, then I 
agree a SIG won't really help. If the latter though, I really think that 
a SIG is a much better way to represent what is happening there, and 
would give the "PowerVM support" SIG extra visibility.

My impression is that it's been 4 years now that those repositories 
exist separately from Nova, Neutron and Ceilometer and nobody seems in a 
hurry to merge that functionality there... which is why I assumed the 
latter.

-- 
Thierry Carrez (ttx)