Robert Collins wrote: > 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.
I'd say you don't need such a job, but then I'm not the one asking for that repository to "be included in next week's cutting of icehouse-3". James asks if I'd be OK to "run through the steps on the How_To_Release wiki", and that wiki page is all about publishing tarballs. So my answer is, if you want to run the release scripts for tripleo-incubator, then you need a tarball job. >> 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). Just saying that IF you want to use the release scripts (and it looks like you actually don't want that), you'll need a 1:1 LP <-> repo match. Currently in LP you have "tripleo" (covering tripleo-* repos), "diskimage-builder", and the os-* projects (which I somehow missed). To reuse the release scripts you'd have to split tripleo in LP into multiple projects. >> 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. I agree with you. I only talked about it because James mentioned it in his "to be released" list. >> 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. My understanding from the etherpad is that you're mainly after stable branches. If that's all you want then it's quite easy: we can just create stable/icehouse branches whenever that makes sense and the interested people can maintain that. If you also want to bless tarballs (a.k.a. "releasing"), then you can push a tag to master and manually upload resulting tarballs to relevant Launchpad pages. In all cases, reusing release scripts or the integrated release process sounds extremely overkill. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev