[openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

Duncan Thomas duncan.thomas at gmail.com
Mon Mar 2 16:07:33 UTC 2015


Why do you say auto-abandon is the wrong tool? I've no problem with the 1
week warning if somebody wants to implement it - I can see the value. A
change-set that has been ignored for X weeks is pretty much the dictionary
definition of abandoned, and restoring it is one mouse click. Maybe put
something more verbose in the auto-abandon message than we have been,
encouraging those who feel it shouldn't have been marked abandoned to
restore it (and respond quicker in future) but other than that we seem to
be using the right tool to my eyes

On 2 March 2015 at 17:17, James E. Blair <corvus at inaugust.com> wrote:

> John Griffith <john.griffith8 at gmail.com> writes:
>
> > For what it's worth, at one point the Cinder project setup an
> auto-abandon
> > job that did purge items that had a negative mark either from a reviewer
> or
> > from Jenkins and had not been updated in over two weeks.  This had
> > absolutely nothing to do with metrics or statistical analysis of the
> > project.  We simply had a hard time dealing with patches that the
> submitter
> > "didn't care about".  If somebody takes the time to review a patch, then
> I
> > don't think it's too much to ask that the submitter respond to questions
> or
> > comments within a two week period.  Note, the auto purge in our case only
> > purged items that had no updates or activity at all.
> >
> > We were actually in a position where we had patches that were submitted,
> > failed unit tests in the gate (valid failures that occurred 100% of the
> > time) and had sat for an entire release without the submitter ever
> updating
> > the patch. I don't think it's unreasonable at all to abandon these and
> > remove them from the queue.  I don't think this is a bad thing, I think
> > it's worse to leave them as active when they're bit-rotted and the
> > submitter doesn't even care about them any longer.  The other thing is,
> > those patches are "still there", they can still be accessed and
> reinstated.
>
> I understand and agree with where you are coming from -- I'm just saying
> that "abandon" is the wrong tool to accomplish this.  If a patch is "in
> the queue" but is failing tests and hasn't been updated in a release,
> then we should find a way to remove it from "the queue" without
> abandoning it.  The solution should not impinge on core reviewers' time.
> I believe we have the tools needed to do this, but have either not
> implemented them or communicated about them correctly.
>
> I'm happy to help identify potential solutions that don't involve
> abandoning others' patches if people would be willing to tell me where
> this is causing them problems.
>
> -Jim
>
> __________________________________________________________________________
> 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
>



-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150302/2bd1893d/attachment.html>


More information about the OpenStack-dev mailing list