Open Stack

From: Dave Walker <email at daviey.com<mailto:email at daviey.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, August 30, 2016 at 4:24 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Requirement for bug when reno is present


On 30 August 2016 at 11:42, Paul Bourke <paul.bourke at oracle.com<mailto:paul.bourke at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160901/3db2c749/attachment.html>