[Development] abandoning stale changes on gerrit

Rutledge Shawn Shawn.Rutledge at digia.com
Thu Jan 31 11:58:13 CET 2013


On 29 Jan 2013, at 8:43 PM, Oswald Buddenhagen wrote:

> On Tue, Jan 29, 2013 at 06:43:34PM +0000, Rutledge Shawn wrote:
>> I do actually abandon stuff when it's quite clear that it's dead, but
>> due to the review and CI processes, there's quite a large percentage
>> of what I write that has hit some sort of obstacle and yet is still a
>> good idea to somehow get done.
>> 
> before somebody gets stupid ideas:

What is this, ad hominem?

I question your right to unilaterally decide to put the kibosh on other people's patches, automatically, across the whole project, even when they are not on your own review list.  You've had enough feedback from others too about _that_ idea.


On 29 Jan 2013, at 8:37 PM, Alan Alpert wrote:
> We're not talking about killing any changes. We're talking about
> making the state in the system match reality - that change has been
> abandoned in practice even if you don't like to face that harsh
> reality. Abandoned is not -2, you can reopen it when you want to do
> something with it again.
> 
> To look at some concrete examples, here are several of your changes
> which I'm a reviewer on which haven't moved since November:
> https://codereview.qt-project.org/#change,38313 - Good idea, still
> needs to be done, but this patch is going nowhere and it could just be
> replaced when (if ever) the new implementation gets pushed.

It took some time to write and test, and could have already gone in if it wasn't for the trouble with the debugging interface.  If I was going to replace it, I probably wouldn't start again from scratch.  If you want to fix it yourself, I wouldn't complain either.  ;-)

> https://codereview.qt-project.org/#change,38433 - Seems to have been
> replaced by a new implementation already

abandoned now

> (https://codereview.qt-project.org/#change,46020)

You are the only one who doesn't like that patch.  Otherwise it could have gone in before Qt 5.0.

> https://codereview.qt-project.org/#change,39624

This patch is the opposite of the previous one, so only one will go in.  But why bring that discussion into this one?  I'm not going to abandon either one of them until one of them is integrated.

> I don't see what the problem is for these to be marked abandoned until
> work resumes on them.

Because they become hard to find.

> Unless you're using your gerrit dashboard as a
> todo list, in which case you need to learn to use JIRA for that.

We all have our own ways of remembering things, so I don't think you should be saying that one of them is wrong if it's actually helpful.

> Also, nagging is *never* the ideal solution. For anything. So I really
> would not like a "nag button" formalized in the process, nagging is
> only for when the process breaks down.

Somebody apparently thought the process already broke down, else this thread wouldn't have started.  But I agree nagging is usually annoying.

> Also try looking at it from the other perspective - we could add a
> filter for you that shows your abandoned patches for easy tracking :)

That's a really good idea, as long as there's a guarantee that abandoned patches don't get deleted until I want them to be.  Then we could label it "deferred", at least that sounds better to me.

As it is, they are hard to find, and I figured somebody is going to unilaterally decide to garbage-collect them some day, if it's not already scheduled.




More information about the Development mailing list