List of Issues with 'patch_abandoned' assigned to them - as of September 2015
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. Leaving the issue with a 'patch_abandoned' label doesn't add anything and puts the issue in a kind of 'limbo' state. As does the 'waiting' status. At what point should I change 'waiting' to 'abandoned'? 6 months? Suggestions welcome. Here is the list: --- INVALID Website rendering problem with navigation bar in IE 6 [2]https://sourceforge.net/p/testlilyissues/issues/1182 Invalid - 2015-09-05 Remove the number of arguments from callback macros [3]https://sourceforge.net/p/testlilyissues/issues/4572 Invalid - 2015-08-22 document that ragged-bottom = #t overrides ragged-last-bottom [4]https://sourceforge.net/p/testlilyissues/issues/347 Invalid - 2015-08-21 Make skipTypesetting skip time signatures. [5]https://sourceforge.net/p/testlilyissues/issues/4142 Invalid - 2014-10-03 Add dead-is-alive boolean property to Hara_kiri_group_spanner [6]https://sourceforge.net/p/testlilyissues/issues/3024 Invalid - 2014-09-02 Let horizontal-line be a straight-cut line rather than having rounded edges [7]https://sourceforge.net/p/testlilyissues/issues/3312 Invalid - 2013-04-16 Set indent based on instrument name [8]https://sourceforge.net/p/testlilyissues/issues/2703 Invalid - 2012-12-22 Changes make test to allow output to be reviewed in a browser [9]https://sourceforge.net/p/testlilyissues/issues/2709 Invalid - 2012-12-22 Change to CG for purely testing purposes [10]https://sourceforge.net/p/testlilyissues/issues/2999 Invalid - 2012-12-02 Allows for framing comments in LilyPond backends. [11]https://sourceforge.net/p/testlilyissues/issues/2073 Invalid - 2012-01-08 Try being a bit more correct and efficient about nested and unnested overrides [12]https://sourceforge.net/p/testlilyissues/issues/3222 Invalid - 2014-08-16 --- DUPLICATE Add StaffAxis context type [13]https://sourceforge.net/p/testlilyissues/issues/4578 Duplicate - 4 days ago Implement \once \revert [14]https://sourceforge.net/p/testlilyissues/issues/4596 Duplicate - 4 days ago Don't clone output definitions across sessions [15]https://sourceforge.net/p/testlilyissues/issues/2871 Duplicate - 2012-10-05 Reverting nested property fails to restore default value if preceded by override in same grob [16]https://sourceforge.net/p/testlilyissues/issues/1063 Duplicate - 2014-08-16 --- ACCEPTED collision flag notehead with polyphony [17]https://sourceforge.net/p/testlilyissues/issues/39 Accepted - 5 days ago Turns beam translation into a callback. [18]https://sourceforge.net/p/testlilyissues/issues/2188 Accepted - 4 days ago RehearsalMark inserts additional space between note columns [19]https://sourceforge.net/p/testlilyissues/issues/3875 Accepted - 2015-09-11 Add support for HairpinText indications [20]https://sourceforge.net/p/testlilyissues/issues/1487 Accepted - 2015-07-23 Attaches bound info to beam for better normalized-endpoint calculations [21]https://sourceforge.net/p/testlilyissues/issues/1693 Accepted - 2015-07-19 Adds glissando stems to lilypond [22]https://sourceforge.net/p/testlilyissues/issues/1727 Accepted - 2015-07-19 Set spanner length as a spanner property [23]https://sourceforge.net/p/testlilyissues/issues/1729 Accepted - 2015-07-19 Adds epsilon to Bezier range calculations [24]https://sourceforge.net/p/testlilyissues/issues/1784 Accepted - 2015-07-19 Enhancement: arrow notation for quarter-tones [25]https://sourceforge.net/p/testlilyissues/issues/1278 Accepted - 2015-07-04 I
Re: List of Issues with 'patch_abandoned' assigned to them - as of September 2015
James Lowe 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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: List of Issues with 'patch_abandoned' assigned to them - as of September 2015
Hello, On 20/09/15 15:01, David Kastrup wrote: > James Lowe 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. > My thinking is like this; I pick an issue to work on, I do some stuff, make a patch, have a discussion, then get bored and go silent. The issue is now patch_abandoned. What is the benefit of leaving this label (or even having it in the first place) as anyone new who wanted to look for an issue would have to start from square 1 anyway or pick up where someone left off (i.e. start from square 2 so to speak), so how is this different from 'Accepted' with no patch label as long as 'someone' (i.e. the Patch Meister) updated the issue tracker with some words? In other words what is the difference between an issue that has had a patch abandoned for 2 years to an issue that has never been started but has been accepted? Assuming the issue is valid of course? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: List of Issues with 'patch_abandoned' assigned to them - as of September 2015
not exactly abandoned, just needs-work since more than three years: http://sourceforge.net/p/testlilyissues/issues/2474/ I forgot I was waiting for feedback, as I believe I answered all raised concerns. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: List of Issues with 'patch_abandoned' assigned to them - as of September 2015
On 20.09.2015 23:10, James Lowe wrote: My thinking is like this; I pick an issue to work on, I do some stuff, make a patch, have a discussion, then get bored and go silent. The issue is now patch_abandoned. What is the benefit of leaving this label (or even having it in the first place) 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? as anyone new who wanted to look for an issue would have to start from square 1 anyway or pick up where someone left off (i.e. start from square 2 so to speak), so how is this different from 'Accepted' with no patch label as long as 'someone' (i.e. the Patch Meister) updated the issue tracker with some words? In other words what is the difference between an issue that has had a patch abandoned for 2 years to an issue that has never been started but has been accepted? 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. Yours, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: List of Issues with 'patch_abandoned' assigned to them - as of September 2015
On 20/09/15 22:52, Simon Albrecht wrote: > On 20.09.2015 23:10, James Lowe wrote: >> >> My thinking is like this; I pick an issue to work on, I do some stuff, >> make a patch, have a discussion, then get bored and go silent. >> >> The issue is now patch_abandoned. >> >> What is the benefit of leaving this label (or even having it in the >> first place) > > 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? Extra cruft that serves no purpose as I can see. We have waiting/needs_work already. >> as anyone new who wanted to look for an issue would have to >> start from square 1 anyway or pick up where someone left off (i.e. start >> from square 2 so to speak), so how is this different from 'Accepted' >> with no patch label as long as 'someone' (i.e. the Patch Meister) >> updated the issue tracker with some words? >> >> In other words what is the difference between an issue that has had a >> patch abandoned for 2 years to an issue that has never been started but >> has been accepted? > > Status is independent of Patch status. Yes that is true and that works well. 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. > 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. Actually 'Fixed' could be also potentially removed as well and the label Fixed_X_x_x be used in it's place. So issues have a status of blank/Accepted/Started/Verified Patch labels of blank/new/review/countdown/needs_work/waiting Other Labels - included the documentation/ugly/enhancement etc. but with the custom label of Fixed_X_x_x as part of that. > Status:Patch_abandoned would mark an issue as ‘suspended’. Suspended for whom? Either an issue is being worked on or it isn't (let's forget those in the patch review process, invalids and duplicates) and we seem to have 'waiting' for that 'suspension' - although I still have a hard time wondering why 'waiting and needs_work' can't be merged, but anyway - this is about abandoned. Started != Patch_new, if for instance someone was working their way to a patch but had to have a conversation with the group or something like that first. Do people look at the 'patch_abandoned' issues differently compared to those that have never been started? I don't know I am not a programmer, but I wouldn't be surprised if they were. > I came to the conclusion that it wasn’t worth the effort of updating all > the DB. Well that's a different topic - and the mass edit if it worked properly, would make that trivial. Ideally we ought to be checking that the really old ones that show some ugly output or similar still apply today. I did that between issues that were raised since 2.11 for the 2.14 / 15 /16 releases (I forget which now). Just to see we hadn't inadvertently fixed something or the way it worked was no longer valid, or it produced a new error and so on. James > > Yours, Simon > > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: List of Issues with 'patch_abandoned' assigned to them - as of September 2015
James Lowe writes: > On 20/09/15 22:52, Simon Albrecht wrote: >> On 20.09.2015 23:10, James Lowe wrote: >>> >>> My thinking is like this; I pick an issue to work on, I do some stuff, >>> make a patch, have a discussion, then get bored and go silent. >>> >>> The issue is now patch_abandoned. >>> >>> What is the benefit of leaving this label (or even having it in the >>> first place) >> >> 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? > > Extra cruft that serves no purpose as I can see. > > We have waiting/needs_work already. Both of those indicate that the Patch is not (yet?) abandoned. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: List of Issues with 'patch_abandoned' assigned to them - as of September 2015
On 21.09.2015 00:18, James Lowe wrote: 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. 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. Actually 'Fixed' could be also potentially removed as well and the label Fixed_X_x_x be used in it's place. How would that fit into the workflow? IIUC, currently Status:Fixed is set by the developer. 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. So issues have a status of blank/Accepted/Started/Verified Much in the same vein: An issue should always have a Status. The current progression/policy is perfectly sensible. Patch labels of blank/new/review/countdown/needs_work/waiting Other Labels - included the documentation/ugly/enhancement etc. but with the custom label of Fixed_X_x_x as part of that. Status:Patch_abandoned would mark an issue as ‘suspended’. Suspended for whom? Either an issue is being worked on or it isn't (let's forget those in the patch review process, invalids and duplicates) and we seem to have 'waiting' for that 'suspension' - although I still have a hard time wondering why 'waiting and needs_work' can't be merged, but anyway - this is about abandoned. I’d not limit discussion to that – we should design a coherent, functional and clear policy and set of values. Started != Patch_new, if for instance someone was working their way to a patch but had to have a conversation with the group or something like that first. Do people look at the 'patch_abandoned' issues differently compared to those that have never been started? I don't know I am not a programmer, but I wouldn't be surprised if they were. I came to the conclusion that it wasn’t worth the effort of updating all the DB. Well that's a different topic - and the mass edit if it worked properly, would make that trivial. Ideally we ought to be checking that the really old ones that show some ugly output or similar still apply today. I also did some checking of the kind, starting from the oldest issues and progressing until 600 (only ‘open’ issues). But this can’t be done as a mass edit: each case must be checked individually. Same is for abandoned patches: the procedure depends on the specific issue. Yours, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
