[Development] abandoning stale changes on gerrit

Chris Adams chris.adams at qinetic.com.au
Thu Jan 31 12:19:05 CET 2013


Hi,


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

Slightly off-topic, but in any event, I think we can all agree that there's
a huge difference between a good QML API and a good C++ API.  I haven't
looked at it, but if Alan thinks that QScreen, as is, shouldn't be exposed
to QML as a property of QQuickItem, then I think that we need some serious
discussion and review before I'd give a +1 to it.  But it's not my area, so
I'll stay out of that one.  I would think that Martin Jones or Andrew den
Exter would have some useful input on those changes, though.


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

Right, and this is the main issue.  Sometimes a patch which seems like a
good idea initially, gets discussed during review and eventually
abandoned.  That discussion might be long and involved, and might include
discussion of internal implementation detail (which rarely get documented
in our classes, for better or worse.  This is a discussion I've had with...
various people over the last couple of years, and on the one hand, if you
document internal stuff in too much detail, then you have to maintain that
documentation as well as the code, when the implementation changes; on the
other hand, I personally like verbose documentation of architecture and
design decisions.  But anyway, the reality is that in many cases, it's not
documented).
In that case, that abandoned review actually becomes a useful resource (you
can refer people to it when discussing the topic of changes in the future,
etc).  Although I would argue that the relevant information should probably
be put into JIRA, in the task related to the change request, but sometimes
that isn't practical (you need the context of the sourcecode for the
comments to make sense, etc).

So, just because a change has been abandoned, doesn't mean that it has zero
value, IMO.

Cheers,
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130131/edafd4e8/attachment.html>


More information about the Development mailing list