Re: [openstack-dev] [searchlight] Liberty release finalization
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
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
Re: [openstack-dev] [searchlight] Liberty release finalization
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
[openstack-dev] [searchlight] Liberty release finalization
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