Open Stack

On Tue, Mar 4, 2014 at 2:08 AM, Thierry Carrez <thierry at openstack.org> wrote:
> 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.
>

+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
--