[openstack-dev] [tripleo] patch abandoment policy

Alex Schultz aschultz at redhat.com
Fri Mar 24 21:25:44 UTC 2017

On Fri, Mar 24, 2017 at 3:16 PM, Dan Prince <dprince at redhat.com> wrote:
> On Thu, 2017-03-23 at 16:20 -0600, Alex Schultz wrote:
>> Hey folks,
>> So after looking at the backlog of patches to review across all of
>> the
>> tripleo projects, I noticed we have a bunch of really old stale
>> patches. I think it's time we address when we can abandon these stale
>> patches.
>> Please comment on the proposed policy[0].  I know this has previously
>> been brought up [1] but I would like to formalize the policy so we
>> can
>> reduce the backlog of stale patches.  If you're wondering what would
>> be abandoned by this policy as it currently sits, I have a gerrit
>> dashboard for you[2] (it excludes diskimage-builder) .
> I think it is fine to periodically review patches and abandon them if
> need be. Last time this came up I wasn't in fan of auto-abandoning
> though. Rather I just made a pass manually and did it in fairly short
> order. The reason I like the manual approach is a lot of ideas could
> get lost (or silently ignored) if nobody acts on them manually.
> Rather then try to automate this would it serve us better to add a link
> to your Gerrit query in [2] below to highlight these patches and
> quickly go through them.

I think that's a valid request. I'm not necessarily that we propose
setting up automation day 1 but at least have a policy that we can
start using to go through this cleanup process.  I referenced
automation in the policy proposal to clear the way if we find that
automation is necessary at sometime in the future.  I think it better
if we started not letting stuff sit for 3 months and work on some
tooling to bring up items earlier.


> Dan
>> Thanks,
>> -Alex
>> [0] https://review.openstack.org/#/c/449332/
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-October/0
>> 76666.html
>> [2] https://goo.gl/XC9Hy7
>> _____________________________________________________________________
>> _____
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
>> cribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list