Open Stack

Robert Collins wrote:
> On 3 March 2014 23:12, Thierry Carrez <thierry at 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)