On Tue, Mar 4, 2014 at 2:08 AM, Thierry Carrez <thie...@openstack.org> wrote: > 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. >
+1, makes sense. I wasn't clear on how that process should work for the tripleo stuff when I made the request. But, I think this conversaition has helped define that for me. Thanks! -- -- James Slagle -- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
