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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
