RFC: STR to GitHub Issue conversion?
15 views
Skip to first unread message
melcher....@googlemail.com
Jan 14, 2023, 1:03:34 PM1/14/23
to fltk.coredev
RFC: should we transfer all 1.x STRs to GitHub and remove STR from fltk.org?
I'll be happy to write a script that should get most or all of the original aspects over
Looking at our roadmap on fltk.org, we still have 51 feature requests and 47 bugs for 1.3 and 108 feature requests and 55 bugs for 1.4 . Now I know that very many of those issues are minor, are obsolete, or have been fixed already in the new GitHub Issue system.
I also know that adding 51+47+108+55=261 new issues to GitHub may make us look quite bad. OTOH, I feel that we rarely get to touch the STRs anymore, and many STRs on fltk.org look just as bad as many Issues on GitHub.
Greg Ercolano
Jan 14, 2023, 1:25:09 PM1/14/23
to fltkc...@googlegroups.com
Sounds tricky given the comments and attachments in the old
STRs,
but if you can figure that out and Albrecht is onboard, I'd say +1.
The current stance on STRs is I think mentioned on the "Bugs and Features" page;
no new STRs, but we'll simply address the old ones the "old fashioned way" and close.
but if you can figure that out and Albrecht is onboard, I'd say +1.
The current stance on STRs is I think mentioned on the "Bugs and Features" page;
no new STRs, but we'll simply address the old ones the "old fashioned way" and close.
Manolo
Jan 14, 2023, 1:34:32 PM1/14/23
to fltk.coredev
Le samedi 14 janvier 2023 à 19:03:34 UTC+1, melcher....@googlemail.com a écrit :
RFC: should we transfer all 1.x STRs to GitHub and remove STR from fltk.org?
I think we should concentrate on having 1.4 out.
melcher....@googlemail.com
Jan 14, 2023, 2:09:43 PM1/14/23
to fltk.coredev
Agreed. I have two pending PRs and one more Issue with 1.4 as a milestone. I'll be done with these by the end of next week.
After that, I will be happy to help out where I can. If there are any more issues that should be in the 1.4 milestone, I'll be happy to take a look at them.
Albrecht Schlosser
Jan 14, 2023, 4:45:12 PM1/14/23
to fltkc...@googlegroups.com
On 1/14/23 19:25 Greg Ercolano wrote:
On 1/14/23 10:03, 'melcher....@googlemail.com' via fltk.coredev wrote:
RFC: should we transfer all 1.x STRs to GitHub and remove STR from fltk.org?
No, definitely not! (see below for details why not ...)
I'll be happy to write a script that should get most or all of the original aspects over
Please don't waste your time writing a script.
Looking at our roadmap on fltk.org, we still have 51 feature requests and 47 bugs for 1.3 and 108 feature requests and 55 bugs for 1.4 . Now I know that very many of those issues are minor, are obsolete, or have been fixed already in the new GitHub Issue system.
My take on this is that the obsolete STR's and those that have
already been fixed should be closed. If possible with a reference to
the GitHub issue and/or the commit that fixed the issue (aka STR).
Minor issues (STR's) should be fixed and closed.
Minor issues (STR's) should be fixed and closed.
I also know that adding 51+47+108+55=261 new issues to GitHub may make us look quite bad. OTOH, I feel that we rarely get to touch the STRs anymore, and many STRs on fltk.org look just as bad as many Issues on GitHub.
But *copying* all STR's to GitHub, including those that "will
*never* be touched" (for whatever reason) is even worse. We'd lose
the overview of open issues and we'd end in chaos.
I've been looking at the STR's from time to time and when I found one that looked as if it had been fixed already or that it could be fixed easily I tried to fix it and closed the STR. This is IMHO the way to go but it should be done more "organized" ...
I've been looking at the STR's from time to time and when I found one that looked as if it had been fixed already or that it could be fixed easily I tried to fix it and closed the STR. This is IMHO the way to go but it should be done more "organized" ...
Sounds tricky given the comments and attachments in the old STRs,
but if you can figure that out and Albrecht is onboard, I'd say +1.
There's no reason to copy *any* STR completely to GitHub. Even if we
closed an STR we could still refer to it on GitHub and continue
working on it on GitHub.
The current stance on STRs is I think mentioned on the "Bugs and Features" page;
no new STRs, but we'll simply address the old ones the "old fashioned way" and close.
Yep, and my opinion is that we should not change this.
Following are some thoughts on STR completion: We have several classes or categories of open STR's. I can't describe all, but I'll try at least for some categories.
(1) Some time ago someone (IIRC Matt ?) looked at *closed* STR's and reopened some of them in the hope that we could fix them in 1.3.x or 1.4.x. I can't tell exactly when that was but we have our newsgroup fltk.bugs at least back to (since) may 2007 (maybe longer). I'm not sure if it's worth to look at it but we might find some STR's that have been reopened but nobody worked on them.
These STR's should be evaluated and possibly closed. Many of them might classify as "obsolete", "won't fix", or "already fixed".
(2) There are many STR's that are assigned to someone. Some of these STR's have already patches or other solutions or proposals. These STR's should be checked by the owner and hopefully fixed and closed quickly. If someone needs help, this here is the right place to ask for help from other devs.
To find "your" STR's you can use the search phrase "developer:your-name" in the search field of STR's. Take care to set the version either to "1.x" or "don't care".
Example: find "my" STR's in 1.x (23 STR's, I don't have 2.x STR's anyway):
https://www.fltk.org/str.php?L+V1.%25+Qdeveloper%3AAlbrechtS
Another search keyword is "creator:username" which finds STR's created by a specific user. You can also combine these to find both STR's you created and own by using "or" in the search field. You can use the wildcard '%' (as usual in SQL) for searches (enter in the search field or use URL encoding '%25').
More info about searching STR's can be found here: https://www.fltk.org/search-help.php
Just for your info: I did a quick search and found STR's owned by (in alphabetical order):
- developer:AlbrechtS: 23
- developer:cand (Lauri): 1
- developer:greg.ercolano: 20
- developer:Matt: 12
You can find all of these in one search by using "developer:%a%" because we all have an 'a' in our names. ;-)
BTW: I checked that these 56 STR's are *all* currently assigned and open STR's.
I'd be glad if we could fix and close these or at least some of these.
(3) All "pending" (22) and "active" (8) STR's should be checked first (low hanging fruits?). Of course, these are all assigned to someone.
(4) "High Priority" or "Critical" STR's should also be checked. Then we can decide whether they can be worked on (fixed, closed), or if they should be transfered to a GitHub Issue.
One thought is to "transfer" only those STR's that are high priority or critical to GitHub - and these STR's should then be added to the release milestone for obvious reasons.
STR's that are likely to be solved in 1.4.0 can be "moved" to GitHub and closed in the STR database with a note and a link to the issue. There *must* be a link to the STR in the GitHub issue and when the issue is completed the commit number should be noted in the STR database for reference.
So, we have 260 public STR's in FLTK 1.x (one is hidden) and of these STR's 56 are assigned to someone. If we could close these we'd be down to about 200 STR's. Still too many to copy them w/o checking to GitHub Issues!
I made a few lists of open STR's and we could all pick ranges of numbers of open STR's to check and fix or close or classify as "worth to investigate".
That all said, my main concern is to avoid "polluting" the GitHub Issues with old and potentially obsolete STR's which we can't resolve anyway.
I'll send the lists of open STR's as a private mail to selected (currently active) devs. The lists are not formatted pretty well but they may help decide if there's something you want to investigate.
PS: while looking at the STR lists I just made, I believe that
STR 2284: Bad return value handling from "getc" in Fl_BMP_Image c'tor
https://www.fltk.org/str.php?L2284
is very likely one of these solved/obsolete STR's which we can close directly. Matt, what do you think? Or anybody else?
Following are some thoughts on STR completion: We have several classes or categories of open STR's. I can't describe all, but I'll try at least for some categories.
(1) Some time ago someone (IIRC Matt ?) looked at *closed* STR's and reopened some of them in the hope that we could fix them in 1.3.x or 1.4.x. I can't tell exactly when that was but we have our newsgroup fltk.bugs at least back to (since) may 2007 (maybe longer). I'm not sure if it's worth to look at it but we might find some STR's that have been reopened but nobody worked on them.
These STR's should be evaluated and possibly closed. Many of them might classify as "obsolete", "won't fix", or "already fixed".
(2) There are many STR's that are assigned to someone. Some of these STR's have already patches or other solutions or proposals. These STR's should be checked by the owner and hopefully fixed and closed quickly. If someone needs help, this here is the right place to ask for help from other devs.
To find "your" STR's you can use the search phrase "developer:your-name" in the search field of STR's. Take care to set the version either to "1.x" or "don't care".
Example: find "my" STR's in 1.x (23 STR's, I don't have 2.x STR's anyway):
https://www.fltk.org/str.php?L+V1.%25+Qdeveloper%3AAlbrechtS
Another search keyword is "creator:username" which finds STR's created by a specific user. You can also combine these to find both STR's you created and own by using "or" in the search field. You can use the wildcard '%' (as usual in SQL) for searches (enter in the search field or use URL encoding '%25').
More info about searching STR's can be found here: https://www.fltk.org/search-help.php
Just for your info: I did a quick search and found STR's owned by (in alphabetical order):
- developer:AlbrechtS: 23
- developer:cand (Lauri): 1
- developer:greg.ercolano: 20
- developer:Matt: 12
You can find all of these in one search by using "developer:%a%" because we all have an 'a' in our names. ;-)
BTW: I checked that these 56 STR's are *all* currently assigned and open STR's.
I'd be glad if we could fix and close these or at least some of these.
(3) All "pending" (22) and "active" (8) STR's should be checked first (low hanging fruits?). Of course, these are all assigned to someone.
(4) "High Priority" or "Critical" STR's should also be checked. Then we can decide whether they can be worked on (fixed, closed), or if they should be transfered to a GitHub Issue.
One thought is to "transfer" only those STR's that are high priority or critical to GitHub - and these STR's should then be added to the release milestone for obvious reasons.
STR's that are likely to be solved in 1.4.0 can be "moved" to GitHub and closed in the STR database with a note and a link to the issue. There *must* be a link to the STR in the GitHub issue and when the issue is completed the commit number should be noted in the STR database for reference.
So, we have 260 public STR's in FLTK 1.x (one is hidden) and of these STR's 56 are assigned to someone. If we could close these we'd be down to about 200 STR's. Still too many to copy them w/o checking to GitHub Issues!
I made a few lists of open STR's and we could all pick ranges of numbers of open STR's to check and fix or close or classify as "worth to investigate".
That all said, my main concern is to avoid "polluting" the GitHub Issues with old and potentially obsolete STR's which we can't resolve anyway.
I'll send the lists of open STR's as a private mail to selected (currently active) devs. The lists are not formatted pretty well but they may help decide if there's something you want to investigate.
PS: while looking at the STR lists I just made, I believe that
STR 2284: Bad return value handling from "getc" in Fl_BMP_Image c'tor
https://www.fltk.org/str.php?L2284
is very likely one of these solved/obsolete STR's which we can close directly. Matt, what do you think? Or anybody else?
Albrecht Schlosser
Jan 14, 2023, 6:24:24 PM1/14/23
to fltkc...@googlegroups.com
On 1/14/23 22:45 Albrecht Schlosser
wrote:
(1) Some time ago someone (IIRC Matt ?) looked at *closed* STR's and reopened some of them in the hope that we could fix them in 1.3.x or 1.4.x. I can't tell exactly when that was but we have our newsgroup fltk.bugs at least back to (since) may 2007 (maybe longer). I'm not sure if it's worth to look at it but we might find some STR's that have been reopened but nobody worked on them.
These STR's should be evaluated and possibly closed. Many of them might classify as "obsolete", "won't fix", or "already fixed".
OK, I found one of these STR's by accident, and then it was easy to
find the sequence of STR changes in fltk.bugs.
Matt fixed many STR's at that time and a long sequence of related STR changes (moving from "1.2" or "2.0" to "1.3.x" and reopening old STR's), beginning on April 22, 2008 (sic!). I didn't have time to check them all yet but I'll probably look into this further tomorrow.
FYI (internal): it's probably newsgroup sequence/id no. 5386 and following, likely up to 5497 on April 25, however there are certainly other activities included.
FWIW.
BTW: I closed meanwhile two STR's (almost 1% of all open STR's) ;-) ;-)
(258 public STR's remaining)
Matt fixed many STR's at that time and a long sequence of related STR changes (moving from "1.2" or "2.0" to "1.3.x" and reopening old STR's), beginning on April 22, 2008 (sic!). I didn't have time to check them all yet but I'll probably look into this further tomorrow.
FYI (internal): it's probably newsgroup sequence/id no. 5386 and following, likely up to 5497 on April 25, however there are certainly other activities included.
FWIW.
BTW: I closed meanwhile two STR's (almost 1% of all open STR's) ;-) ;-)
(258 public STR's remaining)
Albrecht Schlosser
Jan 18, 2023, 11:08:51 AM1/18/23
to fltkc...@googlegroups.com
On 1/14/23 22:45 Albrecht Schlosser
wrote:
My take on this is that the obsolete STR's and those that have already been fixed should be closed. ... Minor issues (STR's) should be fixed and closed.
To simplify this task I added a new feature to the STR list: you can now specify the sort order of the list in a new select box ("Order:").
Current options are:
(0) Status: the default order, as it was before
(1) Updated: order by "Last Updated" column, descending (latest updates on top)
(2) STR #: self explanatory
(3) Assigned: order by "Assigned To" column, unassigned first, then in alphabetical order
The numbers in parentheses above can be used in the URL specification in the new 'O' (uppercase 'o') flag.
Note: You can always get the full URL by clicking on the "Link To Search Results" link or by copying the link with the browser. Note also that (as before) the select boxes don't "react" immediately, you must still click on "Search Requests" to update the search and the link in the "Link To Search Results" link.
BTW, I changed the default version selection to "1.x" because this is what we need most now. The previous value "1.3" was annoying because you'd have to change this to "1.x" in our current status. Note that "1.x" is named "1." in the URL.
Example URL (version = 1.x, sort order = 2 (STR #)):
https://www.fltk.org/str.php?L+P0+S-2+C0+O2+E0+V1.+Q
My main intention to add the sort order option was that I always wanted to have the order "Last Updated" (descending) to be able to see the latest updates on top.
Details (skip this if you're not interested): this new feature uses already available search options and can be modified and extended easily. I'm open for suggestions about new sort options and wishes. We can have multiple sort keys in sequence and each key can be ascending or descending. For instance, the default order is: "-status -priority -scope" which means all three keys are in descending order. The "Assigned" key is "+manager_user -modify_date -status -priority": the main key (assigned developer) is ascending (unassigned first), the other subkeys are descending.
Reply all
Reply to author
Forward
0 new messages