Re: [openstack-dev] [stable] New config options, no default change
What is the text that should be included in the commit messages to make sure that it is picked up for release notes? I'm not sure anyone tracks commit messages to create release notes. Let's use existing DocImpact tag, I'll add check for this in the release scripts. But I prefer if you could directly include the proposed text in the draft release notes (link below) better way to handle this is to create a draft, post it in review comments, and copy to release notes draft right before/after pushing the patch into gate. Forgive me, I think my question is more basic then. Where are the release notes for a stable branch located to make such changes? https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.1#Known_Issues_and_Limitations Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
On 12/02/2014 02:31 AM, Alan Pevec wrote: What is the text that should be included in the commit messages to make sure that it is picked up for release notes? I'm not sure anyone tracks commit messages to create release notes. Let's use existing DocImpact tag, I'll add check for this in the release scripts. But I prefer if you could directly include the proposed text in the draft release notes (link below) I like the idea of using the DocImpact tag to be consistent with what is done in the Master branch. Thanks for the link to the ReleaseNotes wiki page. better way to handle this is to create a draft, post it in review comments, and copy to release notes draft right before/after pushing the patch into gate. Forgive me, I think my question is more basic then. Where are the release notes for a stable branch located to make such changes? https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.1#Known_Issues_and_Limitations Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
- Original Message - From: Alan Pevec ape...@gmail.com To: Jay Bryant jsbry...@electronicjungle.net, OpenStack Development Mailing List (not for usage questions) What is the text that should be included in the commit messages to make sure that it is picked up for release notes? I'm not sure anyone tracks commit messages to create release notes. Let's use existing DocImpact tag, I'll add check for this in the release scripts. But I prefer if you could directly include the proposed text in the draft release notes (link below) Will the bugs created by this end up in the openstack-manuals project (which I don't think is the right place for them in this case) or has it been set up to create them somewhere else (or not at all) when the commits are against the stable branches? -Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
Will the bugs created by this end up in the openstack-manuals project (which I don't think is the right place for them in this case) or has it been set up to create them somewhere else (or not at all) when the commits are against the stable branches? Docs team, how do you handle DocImpact on stable/branches, do you mind (mis)using your tag like this? I thought DocImpat only triggers a notification for the docs team, if there's more machinery behind it like automatic bug filing then we should use a different tag as stable relnotes marker. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
On Tue, Dec 2, 2014 at 2:59 PM, Alan Pevec ape...@gmail.com wrote: Will the bugs created by this end up in the openstack-manuals project (which I don't think is the right place for them in this case) or has it been set up to create them somewhere else (or not at all) when the commits are against the stable branches? Docs team, how do you handle DocImpact on stable/branches, do you mind (mis)using your tag like this? I thought DocImpat only triggers a notification for the docs team, if there's more machinery behind it like automatic bug filing then we should use a different tag as stable relnotes marker. We have recently enabled DocImpact tracking for more projects. DocImpact currently creates a bug in the project indicated by the project's build config in openstack-infra/project-config/gerrit/projects.yaml setting docimpact-group:, such as: docimpact-group: oslo If you want to track your DocImpact feel free to use a Launchpad project for docimpact-group that makes sense to you. Anne Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
- Original Message - From: Anne Gentle a...@openstack.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org On Tue, Dec 2, 2014 at 2:59 PM, Alan Pevec ape...@gmail.com wrote: Will the bugs created by this end up in the openstack-manuals project (which I don't think is the right place for them in this case) or has it been set up to create them somewhere else (or not at all) when the commits are against the stable branches? Docs team, how do you handle DocImpact on stable/branches, do you mind (mis)using your tag like this? I thought DocImpat only triggers a notification for the docs team, if there's more machinery behind it like automatic bug filing then we should use a different tag as stable relnotes marker. We have recently enabled DocImpact tracking for more projects. DocImpact currently creates a bug in the project indicated by the project's build config in openstack-infra/project-config/gerrit/projects.yaml setting docimpact-group:, such as: docimpact-group: oslo If you want to track your DocImpact feel free to use a Launchpad project for docimpact-group that makes sense to you. Anne In this case we're referring to how we handle DocImpact for specific branches of a project (say stable/juno of Nova, for example). I don't think we'd want to change the DocImpact handling for the entire project to go somewhere other than openstack-manuals. As far as I know the current setup doesn't support us changing the handling per branch though, only per project. -Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16/11/14 20:17, Jay S. Bryant wrote: All, This is a question I have been struggling with for Cinder recently. Where do we draw the line on backports. How do we handle config changes? One thing for Cinder I am also considering, in addition to whether it changes the default functionality, is whether it is specific to the submitter's driver. If it is only going to affect the driver I am more likely to consider it than something that is going to impact all of Cinder. What is the text that should be included in the commit messages to make sure that it is picked up for release notes? I want to make sure that people use that. I'm not sure anyone tracks commit messages to create release notes. A better way to handle this is to create a draft, post it in review comments, and copy to release notes draft right before/after pushing the patch into gate. Thanks! Jay On 11/11/2014 06:50 AM, Alan Pevec wrote: New config options may not change behavior (if default value preserves behavior), they still make documentation more incomplete (doc, books, and/or blogposts about Juno won't mention that option). That's why we definitely need such changes described clearly in stable release notes. I also lean to accept this as an exception for stable/juno, I'll request relnote text in the review. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUdI3AAAoJEC5aWaUY1u57YDkH/1LL/Y0gL2egRs1F6pgoaVbk bEREvavZMyV6JFrojfJz2HKVxeo//0AdCcr3+W7KH5pXtposhg3Xf5v6bhF+n0gO NX8u23z2zBLh6xdYcJHiRtMz1zhXT66xDhZso4bMNAL98glGOv1rrbkmkj43pR2L TKSgRyes75nEBOlvPi79Co+2Ti3Z60HbS1NwgqCTGb9yRV3o0JDMZ3+zdFKlrTTf 0ZkrqEHtDaS0wEJmi7vqDAflNBPPn4lo8mAcju9k80lwrCs7g6VdqYJec0Nb/1gJ Foj6vWRPHDH1ftph3am4yhY6Gs+dXQ1nmhEK0zFucDeLXz01Gql3vKX0xK18Rho= =6ABy -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] New config options, no default change
Hi, Looking at a stable/juno cinder proposed change[0], I came across one that introduces a new config option. The default is a noop change for the behaviour, so no bad surprises on upgrade. These sort of changes feel like they are outside the 'no config changes' rule, but we have not really discussed this. What do others think? Thanks [0] https://review.openstack.org/#/c/131987/ -- Kind Regards, Dave Walker ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
On Tue, Nov 11, 2014 at 10:24:41AM +, Dave Walker wrote: Hi, Looking at a stable/juno cinder proposed change[0], I came across one that introduces a new config option. The default is a noop change for the behaviour, so no bad surprises on upgrade. These sort of changes feel like they are outside the 'no config changes' rule, but we have not really discussed this. What do others think? I don't think no config changes is a completely black white rule. The most important part of it is that you don't change the semantics or default values of any existing config options in stable, because that would cause a change in behaviour for existing deployments who upgrade. If backporting a bug fix involves adding a new config parameter I think that's broadly acceptable, provided the config option does not result in a change in behaviour upon upgrade that violates the stable tree requirements. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
Daniel P. Berrange wrote: On Tue, Nov 11, 2014 at 10:24:41AM +, Dave Walker wrote: Hi, Looking at a stable/juno cinder proposed change[0], I came across one that introduces a new config option. The default is a noop change for the behaviour, so no bad surprises on upgrade. These sort of changes feel like they are outside the 'no config changes' rule, but we have not really discussed this. What do others think? I don't think no config changes is a completely black white rule. The most important part of it is that you don't change the semantics or default values of any existing config options in stable, because that would cause a change in behaviour for existing deployments who upgrade. If backporting a bug fix involves adding a new config parameter I think that's broadly acceptable, provided the config option does not result in a change in behaviour upon upgrade that violates the stable tree requirements. New config options may not change behavior (if default value preserves behavior), they still make documentation more incomplete (doc, books, and/or blogposts about Juno won't mention that option). That's why any change requiring a config option to be added needs a stable rules exception to be granted. Stable-maint-core needs to weigh the benefit of the change against the drawbacks, and decide if it's worth it. In the past we accepted a few of those exception requests in case of significant security issues. This one is a bit borderline (security issue, but there are many other ways to achieve the same result). I'd lean towards accepting it, though. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] New config options, no default change
New config options may not change behavior (if default value preserves behavior), they still make documentation more incomplete (doc, books, and/or blogposts about Juno won't mention that option). That's why we definitely need such changes described clearly in stable release notes. I also lean to accept this as an exception for stable/juno, I'll request relnote text in the review. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
