Re: [openstack-dev] Gerrit tooling improvements

[Alexis Lee]

Salvatore Orlando said on Tue, Mar 03, 2015 at 08:21:08PM +0100:
> Is common sense an option here?

Common sense is never an option :)

Mainly because it's situational and hence arises out of shared culture
and expectations, so those not indoctrinated into the group yet get
scolded for lacking common sense, being rude/pushy or giving up too
easily.

Clear, objective, documented criteria are the best way to set policy.
You can get by on common sense until the friction with outsiders gets
too high.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

__
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

[Salvatore Orlando]

Is common sense an option here?
More specifically I mean leveraging the common sense of both contributors
and core reviewers (or whoever is authorized to abandon patches).

The formers should abandon patches they're not working on anymore, and
expect somebody else to do that if the patches they own end up in a stale
condition (where the definition of stale might be relative); the latters
should be very considerate in using this function, using it sparingly and
always providing justification, perhaps not auto generated.

Salvatore

On 3 March 2015 at 19:49, Stefano Maffulli  wrote:

> On Tue, 2015-03-03 at 17:10 +0200, Duncan Thomas wrote:
> > I feel the need to abandon changes that seem abandoned
>
> I think there is an agreement that there should be a way to have a clean
> view of changesets that are being actively worked on, changes where the
> owner is responding to comments, working on it, rebasing as needed, or
> waiting for votes/comments.
>
> For contributors, including the slow ones, I think nobody would object
> that it's also good for them to login on https://review.openstack.org/
> and see the list of their changesets, with votes and comments up where
> they left them (instead of in the "Recently closed").
>
> So I think we go back to tooling: hopefully new version of gerrit will
> have a better way to distinguish 'abandoned' from 'inactive'. Until
> then, what other options do we have?
>
> /stef
>
>
> __
> 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

Re: [openstack-dev] Gerrit tooling improvements

[Stefano Maffulli]

On Tue, 2015-03-03 at 17:10 +0200, Duncan Thomas wrote:
> I feel the need to abandon changes that seem abandoned

I think there is an agreement that there should be a way to have a clean
view of changesets that are being actively worked on, changes where the
owner is responding to comments, working on it, rebasing as needed, or
waiting for votes/comments.  

For contributors, including the slow ones, I think nobody would object
that it's also good for them to login on https://review.openstack.org/
and see the list of their changesets, with votes and comments up where
they left them (instead of in the "Recently closed").

So I think we go back to tooling: hopefully new version of gerrit will
have a better way to distinguish 'abandoned' from 'inactive'. Until
then, what other options do we have?

/stef


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

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

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

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

[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