Re: [openstack-dev] [searchlight] Liberty release finalization

[Nikhil Komawar]

Woohoo! It's a feat!

On 10/6/15 12:19 PM, Tripp, Travis S wrote:
>
> On 10/6/15, 2:28 AM, "Thierry Carrez"  wrote:
>
>> The "intermediary" model requires the project following it to be mature
>> enough (and the project team following it to be disciplined enough) to
>> internalize the QA process.
>>
>> In the "with-milestones" model, you produce development milestones and
>> release candidates to get the features out early and progressively get
>> more and more outside testing on proposed artifacts. It's "ok" if a
>> development milestone is revealed to be unusable: that shows lack of
>> proper testing coverage, and there is still time to fix things before
>> the "real" release.
>>
>> In the "intermediary" model, you deliver fully-usable releases that you
>> recommend production deployments to upgrade to. There is no alpha, beta
>> or RC. You directly tag a release. That means you need to be confident
>> enough in your own testing and testing coverage. Mistakes can still
>> happen (in which case we rush a subsequent point release) but should
>> really be exceptional, otherwise nobody will trust your deliverables.
>>
>> This is why we recommend the "intermediary" model to mature projects and
>> project teams -- that model requires excellent test coverage and
>> discipline inside the team to slow down development as you get closer to
>> a release tag and spend time on testing.
>>
>> -- 
>> Thierry Carrez (ttx)
> Thierry,
>
> Thanks again for the information. After quite a bit of discussion in our IRC 
> channel this morning, we think it does make sense to start with the 
> milestones as recommended.  So, I’ve gone ahead and applied the rc1 tag and 
> will follow up with you in the openstack-relmgr-office for next steps!
>
> Thanks,
> Travis
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Liberty release finalization

[Thierry Carrez]

Tripp, Travis S wrote:
> Thanks for the info! We had discussed the release models a couple times in 
> our IRC meeting and we thought that the release cycle with intermediary 
> releases sounded good to us.  One reason is that we actually wanted to be 
> able to release more frequently if needed support deployers and developers 
> interested in moving searchlight into production more quickly. Possibly we 
> would be looking to release whenever we improve an integration with an 
> existing project, support an integration with a new project, enable a new 
> feature, address major bugs, or to address UI integration needs.
> 
> As far as the version number, we feel that we have a good basis for the 
> functionality and API at this point. We’re wanting to start getting deployer 
> feedback and want to be able to make changes needed without getting too hung 
> up on major vs minor version changes. So we’ve voted to go with 0.1.0 to 
> allow us time to solidify based on that with a goal of going to 1.0 by the 
> end of the Mitaka release cycle.
> 
>  
> However, in reading the page you sent below it says the following about 
> common cycle with intermediary releases.
> 
> "This is especially suitable to more stable projects which add a limited set 
> of new features and don’t plan to go through large architectural changes. 
> Getting the latest and greatest out as often as possible, while ensuring 
> stability and upgradeability."
> 
> This description of the release model sounds a bit dissimilar from our ideas 
> above, so is this okay with you that we stay on that release model?

The "intermediary" model requires the project following it to be mature
enough (and the project team following it to be disciplined enough) to
internalize the QA process.

In the "with-milestones" model, you produce development milestones and
release candidates to get the features out early and progressively get
more and more outside testing on proposed artifacts. It's "ok" if a
development milestone is revealed to be unusable: that shows lack of
proper testing coverage, and there is still time to fix things before
the "real" release.

In the "intermediary" model, you deliver fully-usable releases that you
recommend production deployments to upgrade to. There is no alpha, beta
or RC. You directly tag a release. That means you need to be confident
enough in your own testing and testing coverage. Mistakes can still
happen (in which case we rush a subsequent point release) but should
really be exceptional, otherwise nobody will trust your deliverables.

This is why we recommend the "intermediary" model to mature projects and
project teams -- that model requires excellent test coverage and
discipline inside the team to slow down development as you get closer to
a release tag and spend time on testing.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [searchlight] Liberty release finalization

[Tripp, Travis S]

On 10/6/15, 2:28 AM, "Thierry Carrez"  wrote:

>
>The "intermediary" model requires the project following it to be mature
>enough (and the project team following it to be disciplined enough) to
>internalize the QA process.
>
>In the "with-milestones" model, you produce development milestones and
>release candidates to get the features out early and progressively get
>more and more outside testing on proposed artifacts. It's "ok" if a
>development milestone is revealed to be unusable: that shows lack of
>proper testing coverage, and there is still time to fix things before
>the "real" release.
>
>In the "intermediary" model, you deliver fully-usable releases that you
>recommend production deployments to upgrade to. There is no alpha, beta
>or RC. You directly tag a release. That means you need to be confident
>enough in your own testing and testing coverage. Mistakes can still
>happen (in which case we rush a subsequent point release) but should
>really be exceptional, otherwise nobody will trust your deliverables.
>
>This is why we recommend the "intermediary" model to mature projects and
>project teams -- that model requires excellent test coverage and
>discipline inside the team to slow down development as you get closer to
>a release tag and spend time on testing.
>
>-- 
>Thierry Carrez (ttx)

Thierry,

Thanks again for the information. After quite a bit of discussion in our IRC 
channel this morning, we think it does make sense to start with the milestones 
as recommended.  So, I’ve gone ahead and applied the rc1 tag and will follow up 
with you in the openstack-relmgr-office for next steps!

Thanks,
Travis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [searchlight] Liberty release finalization

[Tripp, Travis S]

Note: I sent a message to Thierry and Doug for help with the specifics of 
running the release and after Theirry’s response it seemed we should include 
the mailing list.

>Tripp, Travis S wrote:
>>Theirry and Doug,
>>We are down to a single patch that needs one more +2 and then we believe 
>>we’ll be ready to run the first Searchlight RC. We have a core reviewer who 
>>will be done going through it by Monday AM US. Can you please let me know 
>>what will be needed from us to run the release?
>>https://launchpad.net/searchlight/+milestone/liberty-rc1
>>(note, the BP under code review and bug in progress are both solved in the 
>>same patch).
>



On 10/5/15, 1:35 AM, "Thierry Carrez"  wrote:

>Hi Travis,
>
>Searchlight is currently registered in the governance as following the
>release cycle with intermediary releases (rather than milestones and
>RCs). It is also *not* directly managed by the release team (yet).
>
>That means you have two options. You can stay with the intermediary
>releases model and just push a tag (1.0.0 or 0.1.0 or...) when you're
>ready for release.
>
>You can switch to a milestone-based model and do a RC: in which case you
>should push a 1.0.0.0rc1 tag.
>
>In both cases you should cut a stable/liberty branch from that (we can
>help with that part).
>
>Then in the milestone-based model case you would re-tag the 1.0.0.0rc1
>with a 1.0.0 tag as we get nearer to final release day. In the
>intermediary model you would only reissue a tag if you detect an issue
>which warrants a 1.0.1 (or 0.1.1) point release.
>
>Try first to decide which model you'd like to follow: the one registered
>in the governance (intermediary) or the one with RCs that you seem to
>follow (milestone-based). Those are described in the project team guide:
>
>http://docs.openstack.org/project-team-guide/release-management.html
>
>-- 
>Thierry Carrez (ttx)
>



Hi Thierry,

Thanks for the info! We had discussed the release models a couple times in our 
IRC meeting and we thought that the release cycle with intermediary releases 
sounded good to us.  One reason is that we actually wanted to be able to 
release more frequently if needed support deployers and developers interested 
in moving searchlight into production more quickly. Possibly we would be 
looking to release whenever we improve an integration with an existing project, 
support an integration with a new project, enable a new feature, address major 
bugs, or to address UI integration needs.

As far as the version number, we feel that we have a good basis for the 
functionality and API at this point. We’re wanting to start getting deployer 
feedback and want to be able to make changes needed without getting too hung up 
on major vs minor version changes. So we’ve voted to go with 0.1.0 to allow us 
time to solidify based on that with a goal of going to 1.0 by the end of the 
Mitaka release cycle.

 
However, in reading the page you sent below it says the following about common 
cycle with intermediary releases.

"This is especially suitable to more stable projects which add a limited set of 
new features and don’t plan to go through large architectural changes. Getting 
the latest and greatest out as often as possible, while ensuring stability and 
upgradeability."

This description of the release model sounds a bit dissimilar from our ideas 
above, so is this okay with you that we stay on that release model?


Thanks,
Travis








__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev