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

2015-03-03 Thread James E. Blair
Sean Dague  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


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  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


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

2015-03-03 Thread Sean Dague
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.

On 03/03/2015 10:10 AM, Duncan Thomas wrote:
> 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  > wrote:
> 
> Duncan Thomas  > 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
> 


-- 
Sean Dague
http://dague.net

__
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 Doug Hellmann


On Tue, Mar 3, 2015, at 10:10 AM, Duncan Thomas wrote:
> 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?

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

Doug

> 
> On 2 March 2015 at 20:44, James E. Blair  wrote:
> 
> > Duncan Thomas  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

__
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