Re: [openstack-dev] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

2015-03-03 Thread James E. Blair
Sean Dague s...@dague.net writes:

 Right, I think this is the 'procedural -2' case, which feels like we
 need another state for things that are being held for procedural
 reasons, which is unrelated to normal code-review.

We have been looking into that and believe we may be able to do
something like that in Gerrit 2.10 using the work-in-progress plugin (to
which we might be able to add another state).

-Jim

__
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-dev] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

2015-03-03 Thread Duncan Thomas
I feel the need to abandon changes that seem abandoned. I believe this has
been covered to death now, so I'm going to shelve that conversation for a
while, and talk about missing tooling in gerrit.

One of the examples of something that was auto-abandoned wrongly was a
patch on hold until some future development cycle (L1 in the case of nova
patches, and cinder batches up certain types of code clean-up commits). So,
one thing that is definitely missing from the tooling is some way of
flagging such patches such that they *don't* get marked as abandoned, at
least until some sensible amount of time after they were supposed to get
picked back up.

So, the semantics of abandonment *certainly don't fit* patches that are
just on hold, but we don't have any way of tagging such patches. Is this
something we can fix?

On 2 March 2015 at 20:44, James E. Blair cor...@inaugust.com wrote:

 Duncan Thomas duncan.tho...@gmail.com writes:

  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

 Why do you feel the need to abandon changes submitted by other people?

 Is it because you have a list of changes to review, and they persist on
 that list?  If so, let's work on making a better list for you.  We have
 the tools.  What query/page/list/etc are you looking at where you see
 changes that you don't want to see?

 -Jim

 __
 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




-- 
Duncan Thomas
__
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] Gerrit tooling improvements(was Re: auto-abandon changesets considered harmful)

2015-03-03 Thread Duncan Thomas
On 3 March 2015 at 17:23, Doug Hellmann d...@doughellmann.com wrote:

 Does the tool ignore patches with Workflow-1 set (work in progress)?


So if it doesn't then we can easily change it to do so, however, I think a
WIP progress patch that hasn't been updated for months counts as abandoned
for any sensible purpose and so should be marked as such.

Sean's comment about a 'procedural do not merge' is pretty bang on really,
a -2 equivalent (preferably one that could be removed by any core, rather
than having to go chase down a particular person to get it removed) would
cover a lot of cases that currently get incorrectly hit by auto-abandon.


-- 
Duncan Thomas
__
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