On 3 March 2014 23:12, Thierry Carrez <thie...@openstack.org> wrote: > James Slagle wrote: >> I'd like to ask that the following repositories for TripleO be included >> in next week's cutting of icehouse-3: >> >> http://git.openstack.org/openstack/tripleo-incubator >> http://git.openstack.org/openstack/tripleo-image-elements >> http://git.openstack.org/openstack/tripleo-heat-templates >> http://git.openstack.org/openstack/diskimage-builder >> http://git.openstack.org/openstack/os-collect-config >> http://git.openstack.org/openstack/os-refresh-config >> http://git.openstack.org/openstack/os-apply-config >> >> Are you willing to run through the steps on the How_To_Release wiki for >> these repos, or should I do it next week? Just let me know how or what >> to coordinate. Thanks. > > I looked into more details and there are a number of issues as TripleO > projects were not really originally configured to be "released". > > First, some basic jobs are missing, like a tarball job for > tripleo-incubator.
Do we need one? tripleo-incubator has no infrastructure to make tarballs. So that has to be created de novo, and its not really structured to be sdistable - its a proving ground. This needs more examination. Slagle could however use a git branch effectively. > Then the release scripts are made for integrated projects, which follow > a number of rules that TripleO doesn't follow: > > - One Launchpad project per code repository, under the same name (here > you have tripleo-* under tripleo + diskimage-builder separately) Huh? diskimage-builder is a separate project, with a separate repo. No conflation. Same for os-*-config, though I haven't made a LP project for os-cloud-config yet (but its not a dependency yet either). > - The person doing the release should be a "driver" (or "release > manager") for the project (here, Robert is the sole driver for > diskimage-builder) Will fix. > - Projects should have an icehouse series and a icehouse-3 milestone James should be able to do this once we have drivers fixed up. > Finally the person doing the release needs to have "push annotated tags" > / "create reference" permissions over refs/tags/* in Gerrit. This seems > to be missing for a number of projects. We have this for all the projects we release; probably not incubator because *we don't release it*- and we had no intent of doing releases for tripleo-incubator - just having a stable branch so that there is a thing RH can build rpms from is the key goal. > In all cases I'd rather limit myself to incubated/integrated projects, > rather than extend to other projects, especially on a busy week like > feature freeze week. So I'd advise that for icehouse-3 you follow the > following simplified procedure: > > - Add missing tarball-creation jobs > - Add missing permissions for yourself in Gerrit > - Skip milestone-proposed branch creation > - Push tag on master when ready (this will result in tarballs getting > built at tarballs.openstack.org) > > Optionally: > - Create icehouse series / icehouse-3 milestone for projects in LP > - Manually create release and upload resulting tarballs to Launchpad > milestone page, under the projects that make the most sense (tripleo-* > under tripleo, etc) > > I'm still a bit confused with the goals here. My original understanding > was that TripleO was explicitly NOT following the release cycle. How > much of the integrated projects release process do you want to reuse ? > We do a feature freeze on icehouse-3, then bugfix on master until -rc1, > then we cut an icehouse release branch (milestone-proposed), unfreeze > master and let it continue as Juno. Is that what you want to do too ? Do > you want releases ? Or do you actually just want stable branches ? This is the etherpad: https://etherpad.openstack.org/p/icehouse-updates-stablebranches - that captures our notes from the summit. TripleO has a whole is not committing to stable maintenance nor API service integrated releases as yet: tuskar is our API service which will follow that process next cycle, but right now it has its guts open undergoing open heart surgery. Everything else we do semver on - like the openstack clients (novaclient etc) - and our overall process is aimed at moving things from incubator into stable trees as they mature. We'll be stabilising the interfaces in tripleo-heat-templates and tripleo-image-elements somehow in future too - but we don't have good answers to some aspects there yet. BUT We want to support members of the TripleO community that are interested in shipping stable editions of TripleO even while it still building up to being a product, which James is leading the effort on - so we need to find reasonable compromises on areas of friction in the interim. Cheers, Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev