Open Stack

Doug :
[snip]
>> I get your point. This would indeed correctly model intermediate releases.
>> But since no other project in Openstack depends on networking-bgpvpn, what is the value of forcing a release of the project synched at the end of a cycle ?
> It raises your chances of having your project packaged in distributions along with the other compatible components, and it clearly tells deployers of your project which versions are meant to go with those other components.

Fair enough. The implicit I had in mind is the relative youth of 
networking-bgpvpn.
What you describe indeed make sense for a mature project.

Maybe what is needed is a way to accommodate with the needs of projects 
in their early days, before they evolve into a cycle release model.


>>> The main issue is your (a) point, especially the "much later" point.
>>> Liberty is in the past now, so making
>>> "liberty" releases now that we are deep in the Mitaka cycle is a bit
>>> weird.
>> "weird" I don't know: isn't it consistent with "release independently” ?
> Again, it’s about signaling where your project fits into the ecosystem of other projects.

See above. I think some project aren't mature enough to advertise that 
they fit in the 6-month cycle release.

>>> When are you likely to start shipping your liberty branch ?
>> We're mostly done and we target November.
>>
>>> Maybe we need a new model to care for such downstream projects when they
>>> can't release in relative sync with the projects they track.
>> I would think so.
>>
>> The reason is that we want to still do the majority of the work in one branch, to avoid the overhead of cherry-picking between branches a large amount of changes (e.g. if we had been working in a liberty branch since September, all this work would have had to be cherry-picked to our master -- and vice-versa: working in master would have meant cherry-picking everything in the liberty branch).
> We call them stable branches because we don’t expect them to receive a lot of new features.
> If you depend on having the final release of neutron for a series available before you can finalize your project, that is indeed a new model.

This is not really the case we are in.
We could technically have targeted to do a liberty release at the same 
time as Openstack, it happens that the project hadn't yet ramped up 
quick enough to allow that (project created early June, many discussion 
on the API in July/August etc.).
So we had to accept doing a delayed release, and it means doing active 
work in a master that targets Liberty.

>   But as I said in my other email, it’s not clear that’s something desirable, and it would be better to have the stadium projects released closer in sync with core neutron.

Yes, a key part of the discussion relates to whether there it is 
desirable or not to allow a project 'master' to target Openstack 
stable/x.  I will would that it does for projects that start, because it 
will help big tent projects do ramp up at their own pace.
Maybe the community will decide that this is not ok for 
x=too-old-a-release, but I would tend to think that this should be 
advertized/enforced by tagging rather than tools built-in rules.

-Thomas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.