Open Stack

Hey, so I think my criteria would be:
 - low chance of user confusion
 - little or no overhead for dev until we're more broadly ready for
long term support

So - if you want to make an incubator release branch thats fine with me but:
 - please make sure the docs in the branch and trunk explain the situation:
    - no guarantee of release -> release stability
    - no guarantee of upgrade stability
    - it's a point-in-time snapshot of a moving story

-Rob

On 18 January 2014 02:18, James Slagle <james.slagle at gmail.com> wrote:
> On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum <clint at fewbar.com> wrote:
>> Note that tripleo-incubator is special and should not be released. It
>> is intentionally kept unfrozen and unreleased to make sure there is no
>> illusion of stability.
>
> I think it would be nice if we could point people at a devtest that
> they could use with our other released stuff. Without that, we might
> make a change to devtest, such as showing the use of a new heat
> parameter in our templates, and if they're trying to follow along with
> a released tripleo-heat-templates then they would have a problem.
>
> Without a branch of incubator, there's no story or documentation
> around using any of our released stuff.  You could follow along with
> devtest to get an idea of how it's supposed to work and indeed it
> might even work, but I don't think that's good enough. There is
> tooling in incubator that has proved it's usefulness. Take an example
> like setup-endpoints, what we're effectively saying without allowing
> people to use that is that there is a useful tool that will setup
> endpoints for you, but don't use it with our released stuff because
> it's not gauranteed to work and instead make these 10'ish calls to
> keystone via some other method. Then you'd also end up with a
> different but parallel set of instructions for using our released
> stuff vs. not.
>
> This is prohibitive to someone who may want to setup a tripleo CI/CD
> cloud deploying stable icehouse or from milestone branches. I think
> people would just create their own fork of tripleo-incubator and use
> that.
>
>> If there are components in it that need releasing, they should be moved
>> into relevant projects or forked into their own projects.
>
> I'd be fine with that approach, except that's pretty much everything
> in incubator, the scripts, templates, generated docs, etc. Instead of
> creating a new forked repo, why don't we just rename tripleo-incubator
> to tripleo-deployment and have some stable branches that people could
> use with our releases?
>
> I don't feel like that precludes tripleo from having no stability on
> the master branch at all.
>
>> Excerpts from Ryan Brady's message of 2014-01-16 07:42:33 -0800:
>>> +1 for releases.
>>>
>>> In the past I requested a tag for tripleo-incubator to make it easier to build a package and test.
>>>
>>> In my case a common tag would be easier to track than trying to gather all of the commit hashes where
>>> the projects are compatible.
>>>
>>> Ryan
>>>
>>> ----- Original Message -----
>>> From: "James Slagle" <james.slagle at gmail.com>
>>> To: "OpenStack Development Mailing List" <openstack-dev at lists.openstack.org>
>>> Sent: Thursday, January 16, 2014 10:13:58 AM
>>> Subject: [openstack-dev] [TripleO] milestone-proposed branches
>>>
>>> At last summit, we talked about doing stable branches and releases for
>>> the TripleO projects for Icehouse.
>>>
>>> I'd like to propose doing a milestone-proposed branch[1] and tagged
>>> release for icehouse milestones 2 and 3. Sort of as dry run and
>>> practice, as I think it could help tease out some things we might not
>>> have considered when we do try to do icehouse stable branches.
>>>
>>> The icehouse milestone 2 date is January 23rd [2]. So, if there is
>>> concensus to do this, we probably need to get the branches created
>>> soon, and then do any bugfixes in the branches (master too of course)
>>> up unitl the 23rd.
>>>
>>> I think it'd be nice if we had a working devtest to use with the
>>> released tarballs.  This raises a couple of points:
>>>  - We probably need a way in devtest to let people use a different
>>> branch (or tarball) of the stuff that is git cloned.
>>> - What about tripleo-incubator itself? We've said in the past we don't
>>> want to attempt to stabilize or release that due to it's "incubator
>>> nature".  But, if we don't have a stable set of devtest instructions
>>> (and accompanying scripts like setup-endpoints, etc), then using an
>>> ever changing devtest with the branches/tarballs is not likely to work
>>> for very long.
>>>
>>> And yes, I'm volunteering to do the work to support the above, and the
>>> release work :).
>>>
>>> Thoughts?
>>>
>>> [1] https://wiki.openstack.org/wiki/BranchModel
>>> [2] https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
>>>
>>> --
>>> -- James Slagle
>>> --
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> -- James Slagle
> --
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud