Neil Jerram <neil.jer...@metaswitch.com> wrote:
Prompted by the thread about maybe allowing subproject teams to do their
own stable maint, I have some questions about what I should be doing in
networking-calico; and I guess the answers may apply generally to
subprojects.
Let's start from the text at
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html:
Stable branches for libraries should be created at the same time when
"libraries"? Should that say "subprojects”?
Yes. Please send a patch to fix wording.
corresponding neutron stable branches are cut off. This is to avoid
situations when a postponed cut-off results in a stable branch that
contains some patches that belong to the next release. This would
require reverting patches, and this is something you should avoid.
(Textually, I think "created" would be clearer here than "cut off", if
that is the intended meaning. "cut off" could also mean "deleted" or
"stop being used”.)
Same.
I think I understand the point here. However, networking-calico doesn't
yet have a stable/liberty branch, and in practice its master branch
currently targets Neutron stable/liberty code. (For example, its
DevStack setup instructions say "git checkout stable/liberty".)
Well that’s unfortunate. You should allow devstack to check out the needed
branch for neutron instead of overwriting its choice.
To get networking-calico into a correct state per the above guideline, I
think I'd need/want to
- create a stable/liberty branch (from the current master, as there is
nothing in master that actually depends on Neutron changes since
stable/liberty)
- continue developing useful enhancements on the stable/liberty branch -
because my primary target for now is the released Liberty - and then
merge those to master
Once spinned out, stable branches should receive bug fixes only. No new
features, db migrations, configuration changes are allowed in stable
branches.
- eventually, develop on the master branch also, to take advantage of
and keep current with changes in Neutron master.
All new features must go to master only. Your master should always be
tested and work with neutron master (meaning, your master should target
Mitaka, not Liberty).
But is that compatible with the permitted stable branch process? It
sounds like the permitted process requires me to develop everything on
master first, then (ask to) cherry-pick specific changes to the stable
branch - which isn't actually natural for the current situation (or
targeting Liberty releases).
Yes, that’s what current stable branch process implies. All stadium
projects must follow the same stable branch process.
Now, you may also not see any value in supporting Liberty, then you can
avoid creating a branch for it; but it seems it’s not the case here.
All that said, we already have stadium projects that violate the usual
process for master (f.e. GBP project targets its master development to kilo
- sic!) I believe that’s something to clear up as part of discussion of
what it really means to be a stadium project. I believe following general
workflow that is common to the project as a whole is one of the
requirements that we should impose.
Ihar
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
