Re: [openstack-dev] [kolla] Requirement for bug when reno is present
release note just generate a bunch of html file. We can not use them for track bug/issue. For example, how to trace the backport/revert/re-open status for some issue/feature if the reno notes is the only thing we have? The reno is just a releasenote tool. It is not helpful for project management. On Tue, Aug 30, 2016 at 6:42 PM, Paul Bourke wrote: > Kolla, > > Do people feel we still want to require a bug-id in the commit message for > features, when reno notes are present? My understanding is that till now > we've required people to add bugs for non trivial features in order to > track them as part of releases. Does/should reno supersede this? > > -Paul > > __ > 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 > -- Regards, Jeffrey Zhang Blog: http://xcodest.me __ 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] [kolla] Requirement for bug when reno is present
sdake kindly took the time to explain the release process. Logs are here: http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2016-09-01.log.html#t2016-09-01T09:06:49 On 30/08/16 20:31, Christian Berendt wrote: On 30 Aug 2016, at 12:42, Paul Bourke wrote: Do people feel we still want to require a bug-id in the commit message for features, when reno notes are present? My understanding is that till now we've required people to add bugs for non trivial features in order to track them as part of releases. Does/should reno supersede this? I think it makes sense to keep the bug/blueprint id because some of our features are distributed in several reviews and only one of the reviews includes the release note. When removing the bug/blueprint ids from the commit message when a reno note will be added with one of the reviews it will be difficult to track the relations. Christian. __ 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 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] [kolla] Requirement for bug when reno is present
From: Dave Walker mailto:em...@daviey.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, August 30, 2016 at 4:24 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [kolla] Requirement for bug when reno is present On 30 August 2016 at 11:42, Paul Bourke mailto:paul.bou...@oracle.com>> wrote: Kolla, Do people feel we still want to require a bug-id in the commit message for features, when reno notes are present? My understanding is that till now we've required people to add bugs for non trivial features in order to track them as part of releases. Does/should reno supersede this? -Paul I'm guess you raised this because my recent comment on a change you did... but actually, I agree with you. I don't think it is a good process, but standardisation is key. The issue comes around because Kolla wanted to use bugs to track potential backports to stable/*. However, I think this is generally overrated and the Change-ID is suitable for this purpose. Open to other options in the future. Can you explain how change Ids can be used to track which bugs need to be backported? I really hate raising bugs "just because", when realistically many of them are not bugs and contain one-line style "Add this $feature" bug description. It just burns through Launchpad bug numbers, and will likely never be looked at again. We shouldn't be using bugs for features IMO and definitely not for release candidates where an FFE hasn't been given. Regards -seve -- Kind Regards, Dave Walker __ 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] [kolla] Requirement for bug when reno is present
> On 30 Aug 2016, at 12:42, Paul Bourke wrote: > > Do people feel we still want to require a bug-id in the commit message for > features, when reno notes are present? My understanding is that till now > we've required people to add bugs for non trivial features in order to track > them as part of releases. Does/should reno supersede this? I think it makes sense to keep the bug/blueprint id because some of our features are distributed in several reviews and only one of the reviews includes the release note. When removing the bug/blueprint ids from the commit message when a reno note will be added with one of the reviews it will be difficult to track the relations. Christian. signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] [kolla] Requirement for bug when reno is present
The bug id and blueprint id are for automatic tracking via Launchpad. If they are omitted, managing the release becomes especially difficult. Unfortunately launchpad doesn't know about reno because then I'd agree, that would be an optimal way too go. Regards -steve On 8/30/16, 3:42 AM, "Paul Bourke" wrote: >Kolla, > >Do people feel we still want to require a bug-id in the commit message >for features, when reno notes are present? My understanding is that till >now we've required people to add bugs for non trivial features in order >to track them as part of releases. Does/should reno supersede this? > >-Paul > >__ >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 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] [kolla] Requirement for bug when reno is present
On 30 August 2016 at 11:42, Paul Bourke wrote: > Kolla, > > Do people feel we still want to require a bug-id in the commit message for > features, when reno notes are present? My understanding is that till now > we've required people to add bugs for non trivial features in order to > track them as part of releases. Does/should reno supersede this? > > -Paul > I'm guess you raised this because my recent comment on a change you did... but actually, I agree with you. I don't think it is a good process, but standardisation is key. The issue comes around because Kolla wanted to use bugs to track potential backports to stable/*. However, I think this is generally overrated and the Change-ID is suitable for this purpose. I really hate raising bugs "just because", when realistically many of them are not bugs and contain one-line style "Add this $feature" bug description. It just burns through Launchpad bug numbers, and will likely never be looked at again. -- Kind Regards, Dave Walker __ 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