lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On issues that are marked as 'Patch_Abandoned'


From: James Lowe
Subject: On issues that are marked as 'Patch_Abandoned'
Date: Sat, 21 Nov 2015 19:14:11 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Hello,



Trying to collate all the that David, Simon and Trevor kindly came up
with (although may end up repeating myself, so my apologies in advance).
I collated the main points from each of the three and have responded,
inline, to those points.

I hope this isn't 'bad form' but the thread was so interlaced with
comments and comments of comments, I wanted to make sure that I didn't
misrepresent or misunderstand anyone.

***

[David K]
A whole bunch of the issues you have below are for Duplicate, Invalid,
or independently Fixed issues. An abandoned patch is natural to go with
that and should not require any additional action. It's only for open
issues that an abandoned patch might form a point of reference.

[JAMES]
What I would like to perhaps suggest here is that those that are
Duplicate, Invalid or Independently fix (i.e. also technically a
duplicate I suppose) can keep those 'Status' entries but the 'Patch'
entry can be moved to 'blank'.

[David K]
The only suspicious combination is an abandoned patch for a Started
issue where the issue owner is the same person responsible for the
patch. That's likely an oversight (or the owner tried to work on a
different patch and lost track at some point of time).

[JAMES]
Which sounds reasonable. Hence the point about removing the Patch entry
(i.e. setting it to blank) and making sure the Status field is set
accordingly (Invalid or Duplicate).

[David K]
I don't think abandoned patches require any action of their own.
"Started" issues may independently be considered as not being worked on
after a considerable amount of time.

[JAMES]
Would 9 months be acceptable as a 'considerable amount of time'? I can
then start on trying to make sure that I go back as far as necessary
(i.e. everything before April/May of this year) and then try to keep on
top of it each month thereafter; trying to make sure that issues marked
'abandoned' are never older than 6 months.

[David K]
In that case, it might get disowned, reset to "Accepted" (when it's
still relevant) and _possibly_ any existing patch may be marked
"abandoned" in that process.

[JAMES]
Certainly it should get set to 'blank' owner I think (and put back to
'Accepted'). Anything younger than 9 months (see my last comment above)
would still be marked as 'abandoned' (if not already). If the previous
owner disagrees or still wants to 'own' the issue (whatever that may
mean for them) then they can always update the ticket accordingly. This
would have two effects; first the issue would be 'updated' in terms of
its 'last edited' date (so to speak) bringing it forward from any
6-month-or-older filter, and secondly the Issue would have an entry -
either just the Owner and Status change and/or a 'I am still working on
this' entry in the thread. This puts the onus back on the developer and
if they choose to do nothing, then that can be assumed to remove doubt
on the state of the issue for others who may want to work it or who may
be ignoring it, thinking that the other developer is still doing
something (Graham P's universal 'Law of the 'Hot Potato'!)

[David K]
But I don't think that any patch already marked "abandoned" necessitates
any further action on its own.

[JAMES]
Well I think that 'depends' (see my previous replies above for my
reasoning).

***

[Simon A]
One can see immediately that a patch has already been prepared for this
issue, which may serve as a starting point for future work. True,
anybody to pick up such an issue would have to read through the entire
discussion anyway, but I’d rather ask the other way round:
What’s the benefit of deleting the Patch label, or the harm that a
Patch:abandoned does?

[JAMES]
My further thoughts on what I said before were if a patch was only
abandoned because a developer gave up or ran out of time (or something
similar to that) other than the fact it was 'Invalid' or 'Duplicate';
then I think there is no benefit of being left with the 'Patch
abandoned' label and that it might - subconsciously or otherwise - cause
other potential developers to 'ignore' the issue simply because of
having that label (I don't know how developers' minds work in that
regard I must admit). So *not* having, or rather, putting the Patch back
to 'blank', I think, always gains something at least psychologically.

I hope that made sense?

[Simon A]
> [David K] Status is independent of Patch status.
True, I did myself make some thoughts on merging those two fields: i.e.
replacing Status:Started by Status:Patch_new etc. After all,
Status:Fixed would be a fitful successor to Status:Patch_push.
Status:Patch_abandoned would mark an issue as ‘suspended’.
I came to the conclusion that it wasn’t worth the effort of updating all
the DB.

[JAMES]
Not so much that, as having yet another status ('suspended') doesn't
gain us anything think. We already have 'Waiting' - which is something
that I don't really think is clear either (but that is for another time,
I want to just get 'Patch Abandoned' sorted first).


****
> [James] The 'new' status was for those issues that had been added by
random Joes
> (not members of the bug squad) and then it was changed to 'Accepted'
> once the issue was checked - else it would be marked invalid or
> duplicate (or even merged). If we're going to keep 'blank' then we could
> even do way with the 'new' status.
>
>
>      
>> [Simon] True, I did myself make some thoughts on merging those two
fields: i.e.
>> replacing Status:Started by Status:Patch_new etc. After all,
>> Status:Fixed would be a fitful successor to Status:Patch_push.

> [James] Actually 'Fixed' could be also potentially removed as well and
the label
> Fixed_X_x_x be used in it's place.

[Simon] How would that fit into the workflow? IIUC, currently
Status:Fixed is set by the developer.

[James]. Yes - or the committer.

[Simon] The bug squad member verifies and then sets Status:Verified and
Label:Fixed_X_x_x. Label and Status should definitely not get mixed up,
if you ask me.

[James] I don't think they would get mixed up - what I am (sort of)
proposing is a way to 'reset' any incident that is not Invalid/Duplicate
and is 'patch_abandoned' back to 'as if' had been 'Accepted' but had not
been started. Patches that are Invalid/Duplicate would have the
'patch_abandoned' status, if it had one, removed and also any dev name,
if there was one, as well.

****

[Trevor]
The key difference is one of ownership.  The LP developers have
a tradition of not interfering (other than by commenting) on the development
of a patch to an issue already "owned" by someone else.  Patch
waiting/needs_work means the current owner is still planning to do more
work, so other devs let it ride.  Patch abandoned means the previous
dev has given up, so anyone else is free to take it up and change the
ownership.  Well, at least that's my understanding.

[David]
No, that's not entirely related.  I may give up on a particular approach
to an issue, making it pointless to pursue a particular patch, but still
want to cook up a different patch or solve the problem in the context of
another issue.  Patch abandoned just means that the latest proposed
patch is not going to be pursued further, not that the issue owner has
given up on a particular problem altogether.

[Trevor]
We don't really have a mechanism to handle multiple patches, so I think
we can discount that possibility.

[David]
Sorry, but that just does not match reality.  We have a host of issues
where multiple patches have been proposed.  While we only assign a state
to the latest patch with a reference in a comment, this state has a
number of degrees of freedom independent from that of the issue.

[Trevor]
We usually use Patch needs_work to
cover the situation where the current patch is inadequate and further work
is in progress.  I'd rather adopt my interpretation as a more useful use
of this limited set of markers, namely that Patch abandoned really means,
"I've given up on working on this issue and the current patch is now up for
grabs for someone else to improve on it." 

[David]
That's issue ownership.  And the difference between "Started" and
"Accepted".

[Trevor]
And I'd suggest an issue should
be placed in this state by the Bug Squad if no action on it has been
apparent
by the current owner for over 6 months.

[James]
The very least, I suppose, that dev who was still 'pursuing' a different
approach could be metaphorically kicked into stating their intentions in
the issue itself if it appeared that the issue was stagnating with an
out of date patch and no update for a period of time. I'm just about
removing the doubt for other/new contributors.

[Trevor]
OK, I can accept that.  So, to elaborate a little on James' post,
the point of which is to enable some old inactive issues/patches
to be cleared up, in the event of inaction for 6 months (say):

  Status:Started -> Status:Accepted
  Owner -> ""
  Patch: needs_work -> Patch:abandoned

So the final state of an issue which has been inactive for more
than 6 months reverts to "Accepted" with no Owner, and the final
state of the latest associated patch reverts to "abandoned" or
remains "waiting", and in the latter case this should be qualified
by the Needs field.  That makes it clear the issue is free to be
picked up by someone else, either by starting from scratch or
continuing to develop an earlier abandoned patch.

[James]
I like that.


On 20/09/15 15:01, David Kastrup wrote:
> James Lowe <address@hidden> writes:
>
>>    Hello,
>>    As part of the 'Patch Meister's' role, I present the following list of
>>    all issues currently marked as 'patch_abandoned'.
>>    I've grouped them into their patch 'Status' fields and then shown the
>>    date that the last time the issue was updated.
>>    For those that cannot remember, Issue classification definitions are
>>    here:
>>   
[1]http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#iss
>>    ue-classification
>>    We should make some decision on what to do with these. In my opinion,
>>    the very least we should change the status to either 'new', 'invalid'
>>    or 'blank'. My own feeling that we not use the 'patch_abandoned' label
>>    anymore, in that if an Issue is 'abandoned', it is usually abandoned
>>    because of
>>    i. Dev has no more time or has given up working on the patch for a
>>    'started' issue - perhaps set issue back to 'new' and remove patch
>>    status label; but put a note in the thread that the patch was
>>    abandoned.
>>    ii. The issue has been shown to no longer be applicable (because of a
>>    change in either the code base, or for example in the case of
trying to
>>    support some deprecated third-party code - like an OS or Browser etc.)
>>    In which case this should probably be changed to 'Invalid' and be
done.
>>    Other than those two (variations on a theme) I cannot think of
anything
>>    other case.
>
> A whole bunch of the issues you have below are for Duplicate, Invalid,
> or independently Fixed issues.  An abandoned patch is natural to go with
> that and should not require any additional action.  It's only for open
> issues that an abandoned patch might form a point of reference.
>
> The only suspicious combination is an abandoned patch for a Started
> issue where the issue owner is the same person responsible for the
> patch.  That's likely an oversight (or the owner tried to work on a
> different patch and lost track at some point of time).  So basically
> I don't think abandoned patches require any action of their own.
> "Started" issues may independently be considered as not being worked on
> after a considerable amount of time.  In that case, it might get
> disowned, reset to "Accepted" (when it's still relevant) and _possibly_
> any existing patch may be marked "abandoned" in that process.
>
> But I don't think that any patch already marked "abandoned" necessitates
> any further action on its own.
>


-- 
James

-------

B8F4 5395 CBE2 ED37 7513 B075 FF32 5682 A84B D8BE

-- 
James

-------

B8F4 5395 CBE2 ED37 7513 B075 FF32 5682 A84B D8BE




reply via email to

[Prev in Thread] Current Thread [Next in Thread]