Re: [Scons-dev] bug prune
Expanding on Russel's comment, the SCons project is a broad church that nominally supports a very large number of languages. I think old issues reflect the relative interest from the comminity for supporting a particular language and/or feature of SCons (e.g. people care a lot more about continued support for MSVC, less about Java). Perhaps all that's required is expectation management? The readme is already quite large, but something in there? Andrew On Thu, 5 Sep 2019 at 20:01, Bill Deegan wrote: > O.k. > I'll try to get this setup this weekend. > > On Thu, Sep 5, 2019 at 3:47 AM Russel Winder wrote: > >> On Tue, 2019-09-03 at 11:44 -0700, Bill Deegan wrote: >> > On one hand dropping the number of open bugs will have significant >> > appearance/PR improvements. >> > (I've seen comments saying 600+ bugs outstanding the project must not be >> > still alive). >> >> I'd say having a lot of open bugs in a project that clearly has regular >> commits (as SCons does) could lead to the the thought that the SCons team >> doesn't care about submitted issues – rather than being a dead project. >> >> Age of bugs is also a dimension. Bugs open for more than a few years >> indicate >> a "no-one actually cares about this" and so are candidates for closing >> with >> the option of reopening – or better a new bug opening given the difference >> between the software now compared to then. >> >> > But dropping 620 of 680 bugs because they're stale, but possibly still >> > unresolved issues probably isn't the best. >> >> It depends. Some may just not be relevant any more. Given the rate of >> change >> of SCons code base, any bug report unaddressed in say five years should be >> closed. >> >> > Would we tag them stale and close them, allowing them to be identified >> as >> > possibly not resolved, but with no recent activity? >> >> Or delete them in the hope of getting a new bug report if the problem is >> still >> a real one. >> >> > We used to have weekly (ish) bug triage IRC meetings. >> > Though to be honest some issues never got addressed because the time >> > required to thoroughly investigate them and resolve and the few people >> > reporting them dropped their effective priority. >> > >> > Thoughts? >> >> I was never able to get involved in triaging since the meeting were always >> held as a time when I was in bed a sleep. >> >> -- >> Russel. >> === >> Dr Russel Winder t: +44 20 7585 2200 >> 41 Buckmaster Roadm: +44 7770 465 077 >> London SW11 1EN, UK w: www.russel.org.uk >> >> ___ >> Scons-dev mailing list >> Scons-dev@scons.org >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
O.k. I'll try to get this setup this weekend. On Thu, Sep 5, 2019 at 3:47 AM Russel Winder wrote: > On Tue, 2019-09-03 at 11:44 -0700, Bill Deegan wrote: > > On one hand dropping the number of open bugs will have significant > > appearance/PR improvements. > > (I've seen comments saying 600+ bugs outstanding the project must not be > > still alive). > > I'd say having a lot of open bugs in a project that clearly has regular > commits (as SCons does) could lead to the the thought that the SCons team > doesn't care about submitted issues – rather than being a dead project. > > Age of bugs is also a dimension. Bugs open for more than a few years > indicate > a "no-one actually cares about this" and so are candidates for closing with > the option of reopening – or better a new bug opening given the difference > between the software now compared to then. > > > But dropping 620 of 680 bugs because they're stale, but possibly still > > unresolved issues probably isn't the best. > > It depends. Some may just not be relevant any more. Given the rate of > change > of SCons code base, any bug report unaddressed in say five years should be > closed. > > > Would we tag them stale and close them, allowing them to be identified as > > possibly not resolved, but with no recent activity? > > Or delete them in the hope of getting a new bug report if the problem is > still > a real one. > > > We used to have weekly (ish) bug triage IRC meetings. > > Though to be honest some issues never got addressed because the time > > required to thoroughly investigate them and resolve and the few people > > reporting them dropped their effective priority. > > > > Thoughts? > > I was never able to get involved in triaging since the meeting were always > held as a time when I was in bed a sleep. > > -- > Russel. > === > Dr Russel Winder t: +44 20 7585 2200 > 41 Buckmaster Roadm: +44 7770 465 077 > London SW11 1EN, UK w: www.russel.org.uk > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
On Tue, 2019-09-03 at 11:44 -0700, Bill Deegan wrote: > On one hand dropping the number of open bugs will have significant > appearance/PR improvements. > (I've seen comments saying 600+ bugs outstanding the project must not be > still alive). I'd say having a lot of open bugs in a project that clearly has regular commits (as SCons does) could lead to the the thought that the SCons team doesn't care about submitted issues – rather than being a dead project. Age of bugs is also a dimension. Bugs open for more than a few years indicate a "no-one actually cares about this" and so are candidates for closing with the option of reopening – or better a new bug opening given the difference between the software now compared to then. > But dropping 620 of 680 bugs because they're stale, but possibly still > unresolved issues probably isn't the best. It depends. Some may just not be relevant any more. Given the rate of change of SCons code base, any bug report unaddressed in say five years should be closed. > Would we tag them stale and close them, allowing them to be identified as > possibly not resolved, but with no recent activity? Or delete them in the hope of getting a new bug report if the problem is still a real one. > We used to have weekly (ish) bug triage IRC meetings. > Though to be honest some issues never got addressed because the time > required to thoroughly investigate them and resolve and the few people > reporting them dropped their effective priority. > > Thoughts? I was never able to get involved in triaging since the meeting were always held as a time when I was in bed a sleep. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
On one hand dropping the number of open bugs will have significant appearance/PR improvements. (I've seen comments saying 600+ bugs outstanding the project must not be still alive). But dropping 620 of 680 bugs because they're stale, but possibly still unresolved issues probably isn't the best. Would we tag them stale and close them, allowing them to be identified as possibly not resolved, but with no recent activity? We used to have weekly (ish) bug triage IRC meetings. Though to be honest some issues never got addressed because the time required to thoroughly investigate them and resolve and the few people reporting them dropped their effective priority. Thoughts? On Mon, Sep 2, 2019 at 7:30 AM Mats Wichmann wrote: > On 9/2/19 8:03 AM, Jonathon Reinhart wrote: > > Note that you can subscribe to a GitHub issue without commenting. This > > is preferred as it avoids spamming all currently-subscribed users. > > > > Also, I think mass/automated bug closing needs to be done very > > conservatively. Closing an issue doesn't make the bug go away. There are > > projects that have bots which close issues after 30 days of inactivity, > > and I find it infuriating. > > I'm not a fan of the rapid/aggressive closing either, wasn't suggesting > that. The idea of a bot is to keep there from being so much manual work > to get the notifications sent, and the closing done. If the team prefers > no not keep it after the prune, it can just be turned off. > > There are a decent number of bugs that were created over 10 years ago, > and many in the 3-10 year range, and which, due to the migration from > tigris, aren't really associated with people who may have reported them, > or commented on them. > > The idea of commenting to keep a bug alive is to defeat the bot's idea > of what is active (and to confirm "yes, this is still a problem"). I > don't think subscribing to it does that. > > > > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
That makes sense, Mats. Thanks for the additional insight. On Mon, Sep 2, 2019, 10:30 Mats Wichmann wrote: > On 9/2/19 8:03 AM, Jonathon Reinhart wrote: > > Note that you can subscribe to a GitHub issue without commenting. This > > is preferred as it avoids spamming all currently-subscribed users. > > > > Also, I think mass/automated bug closing needs to be done very > > conservatively. Closing an issue doesn't make the bug go away. There are > > projects that have bots which close issues after 30 days of inactivity, > > and I find it infuriating. > > I'm not a fan of the rapid/aggressive closing either, wasn't suggesting > that. The idea of a bot is to keep there from being so much manual work > to get the notifications sent, and the closing done. If the team prefers > no not keep it after the prune, it can just be turned off. > > There are a decent number of bugs that were created over 10 years ago, > and many in the 3-10 year range, and which, due to the migration from > tigris, aren't really associated with people who may have reported them, > or commented on them. > > The idea of commenting to keep a bug alive is to defeat the bot's idea > of what is active (and to confirm "yes, this is still a problem"). I > don't think subscribing to it does that. > > > > > ___ > Scons-dev mailing list > Scons-dev@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
On 9/2/19 8:03 AM, Jonathon Reinhart wrote: > Note that you can subscribe to a GitHub issue without commenting. This > is preferred as it avoids spamming all currently-subscribed users. > > Also, I think mass/automated bug closing needs to be done very > conservatively. Closing an issue doesn't make the bug go away. There are > projects that have bots which close issues after 30 days of inactivity, > and I find it infuriating. I'm not a fan of the rapid/aggressive closing either, wasn't suggesting that. The idea of a bot is to keep there from being so much manual work to get the notifications sent, and the closing done. If the team prefers no not keep it after the prune, it can just be turned off. There are a decent number of bugs that were created over 10 years ago, and many in the 3-10 year range, and which, due to the migration from tigris, aren't really associated with people who may have reported them, or commented on them. The idea of commenting to keep a bug alive is to defeat the bot's idea of what is active (and to confirm "yes, this is still a problem"). I don't think subscribing to it does that. ___ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
Note that you can subscribe to a GitHub issue without commenting. This is
preferred as it avoids spamming all currently-subscribed users.
Also, I think mass/automated bug closing needs to be done very
conservatively. Closing an issue doesn't make the bug go away. There are
projects that have bots which close issues after 30 days of inactivity, and
I find it infuriating.
On Tue, Aug 27, 2019, 08:50 Mats Wichmann wrote:
>
> Just to pull some thoughts together:
>
> there are currently 679 open scons issues on github.
>
> That number drops to 92 if you select only ones which have had a
> modification since the big migration from tigris. Try this query:
>
> is:issue is:open updated:>=2018-02-10
>
> or as a link:
>
>
> https://github.com/SCons/scons/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+updated%3A%3E%3D2018-02-10+
>
> I'm a relative newcomer around here, but I don't see the value of
> showing a ton of historical bugs that aren't being worked on; the newly
> filed ones don't even get a lot of attention - there just isn't a big
> scons team at this point and numerically most current contributors have
> a specific motivation ("itch to scratch" as it were) rather than the
> ability to just generally work on bugs. To provide more visible focus
> there's already been some discussion of a bug prune.
>
> My suggestion is this:
>
> (a) close all open tigris bugs with a message that includes these items:
>
> * bug is now tracked on github [link]
> * bugs which have not had activity in 18 months are going to be closed
> (it doesn't have to be 18, but that was the cutover time)
> * we understand readers of this issue might not see messages from
> github, so if you want to keep this issue alive, make a comment - any
> comment - on the corresponding github issue.
>
> (b) fire up a bot to mark inactive github issues with a tag, and
> configure suitably. Looks like there's an app in the github marketplace
> that is free so setup is just a YAML file. Example setup here:
>
>
> https://github.com/timgrossmann/InstaPy/commit/afd968dfa1ce1141456a207484d35f2766d5916b
>
> the app:
>
> https://github.com/marketplace/stale
>
> (c) someone scan through the first-time closure proposal list and
> manually update any which seem deserving of continued life.
>
>
> Closed-as-stale issues don't vanish, they are still there to be browsed
> as needed...
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
Dirk,
If you can create a HTML dump, I can put it up on the scons.org webserver
and link to it.
And then maybe we create a repo to check in all the source files with
scripts to regen?
-Bill
On Sat, Aug 31, 2019 at 5:09 AM Dirk Bächle wrote:
> Hi,
>
> this approach sounds good to me too. I just wanted to mention that I have
> all the old Tigris Issues (and user and developer mails)
> archived on my local machine. They're stored in a simple text-ish format
> that can be read into corresponding Python classes.
> My plan is still to write a small "viewer" app, that would enable
> interested developers/users to "browse" through the "SCons
> archives". In my view there is a lot of hidden knowledge in there, that we
> can't really use at the moment.
>
> I'll try to check whether my "archive" is still up-to-date during the next
> days. ;)
>
> Best regards,
>
> Dirk
>
> On 27.08.19 15:53, Gary Oberbrunner wrote:
> > I think this would be great. I'll help review the bugs-to-be-closed.
> >
> > -- Gary
> >
> > On Tue, Aug 27, 2019 at 8:50 AM Mats Wichmann m...@wichmann.us>> wrote:
> >
> >
> > Just to pull some thoughts together:
> >
> > there are currently 679 open scons issues on github.
> >
> > That number drops to 92 if you select only ones which have had a
> > modification since the big migration from tigris. Try this query:
> >
> > is:issue is:open updated:>=2018-02-10
> >
> > or as a link:
> >
> >
> https://github.com/SCons/scons/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+updated%3A%3E%3D2018-02-10+
> >
> > I'm a relative newcomer around here, but I don't see the value of
> > showing a ton of historical bugs that aren't being worked on; the
> newly
> > filed ones don't even get a lot of attention - there just isn't a big
> > scons team at this point and numerically most current contributors
> have
> > a specific motivation ("itch to scratch" as it were) rather than the
> > ability to just generally work on bugs. To provide more visible
> focus
> > there's already been some discussion of a bug prune.
> >
> > My suggestion is this:
> >
> > (a) close all open tigris bugs with a message that includes these
> items:
> >
> > * bug is now tracked on github [link]
> > * bugs which have not had activity in 18 months are going to be
> closed
> > (it doesn't have to be 18, but that was the cutover time)
> > * we understand readers of this issue might not see messages from
> > github, so if you want to keep this issue alive, make a comment - any
> > comment - on the corresponding github issue.
> >
> > (b) fire up a bot to mark inactive github issues with a tag, and
> > configure suitably. Looks like there's an app in the github
> marketplace
> > that is free so setup is just a YAML file. Example setup here:
> >
> >
> https://github.com/timgrossmann/InstaPy/commit/afd968dfa1ce1141456a207484d35f2766d5916b
> >
> > the app:
> >
> > https://github.com/marketplace/stale
> >
> > (c) someone scan through the first-time closure proposal list and
> > manually update any which seem deserving of continued life.
> >
> >
> > Closed-as-stale issues don't vanish, they are still there to be
> browsed
> > as needed...
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
> >
> >
> > --
> > Gary
> >
> > ___
> > Scons-dev mailing list
> > Scons-dev@scons.org
> > https://pairlist2.pair.net/mailman/listinfo/scons-dev
> >
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
Hi,
this approach sounds good to me too. I just wanted to mention that I have all
the old Tigris Issues (and user and developer mails)
archived on my local machine. They're stored in a simple text-ish format that
can be read into corresponding Python classes.
My plan is still to write a small "viewer" app, that would enable interested developers/users
to "browse" through the "SCons
archives". In my view there is a lot of hidden knowledge in there, that we
can't really use at the moment.
I'll try to check whether my "archive" is still up-to-date during the next
days. ;)
Best regards,
Dirk
On 27.08.19 15:53, Gary Oberbrunner wrote:
I think this would be great. I'll help review the bugs-to-be-closed.
-- Gary
On Tue, Aug 27, 2019 at 8:50 AM Mats Wichmann mailto:m...@wichmann.us>> wrote:
Just to pull some thoughts together:
there are currently 679 open scons issues on github.
That number drops to 92 if you select only ones which have had a
modification since the big migration from tigris. Try this query:
is:issue is:open updated:>=2018-02-10
or as a link:
https://github.com/SCons/scons/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+updated%3A%3E%3D2018-02-10+
I'm a relative newcomer around here, but I don't see the value of
showing a ton of historical bugs that aren't being worked on; the newly
filed ones don't even get a lot of attention - there just isn't a big
scons team at this point and numerically most current contributors have
a specific motivation ("itch to scratch" as it were) rather than the
ability to just generally work on bugs. To provide more visible focus
there's already been some discussion of a bug prune.
My suggestion is this:
(a) close all open tigris bugs with a message that includes these items:
* bug is now tracked on github [link]
* bugs which have not had activity in 18 months are going to be closed
(it doesn't have to be 18, but that was the cutover time)
* we understand readers of this issue might not see messages from
github, so if you want to keep this issue alive, make a comment - any
comment - on the corresponding github issue.
(b) fire up a bot to mark inactive github issues with a tag, and
configure suitably. Looks like there's an app in the github marketplace
that is free so setup is just a YAML file. Example setup here:
https://github.com/timgrossmann/InstaPy/commit/afd968dfa1ce1141456a207484d35f2766d5916b
the app:
https://github.com/marketplace/stale
(c) someone scan through the first-time closure proposal list and
manually update any which seem deserving of continued life.
Closed-as-stale issues don't vanish, they are still there to be browsed
as needed...
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
Re: [Scons-dev] bug prune
I think this would be great. I'll help review the bugs-to-be-closed.
-- Gary
On Tue, Aug 27, 2019 at 8:50 AM Mats Wichmann wrote:
>
> Just to pull some thoughts together:
>
> there are currently 679 open scons issues on github.
>
> That number drops to 92 if you select only ones which have had a
> modification since the big migration from tigris. Try this query:
>
> is:issue is:open updated:>=2018-02-10
>
> or as a link:
>
>
> https://github.com/SCons/scons/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+updated%3A%3E%3D2018-02-10+
>
> I'm a relative newcomer around here, but I don't see the value of
> showing a ton of historical bugs that aren't being worked on; the newly
> filed ones don't even get a lot of attention - there just isn't a big
> scons team at this point and numerically most current contributors have
> a specific motivation ("itch to scratch" as it were) rather than the
> ability to just generally work on bugs. To provide more visible focus
> there's already been some discussion of a bug prune.
>
> My suggestion is this:
>
> (a) close all open tigris bugs with a message that includes these items:
>
> * bug is now tracked on github [link]
> * bugs which have not had activity in 18 months are going to be closed
> (it doesn't have to be 18, but that was the cutover time)
> * we understand readers of this issue might not see messages from
> github, so if you want to keep this issue alive, make a comment - any
> comment - on the corresponding github issue.
>
> (b) fire up a bot to mark inactive github issues with a tag, and
> configure suitably. Looks like there's an app in the github marketplace
> that is free so setup is just a YAML file. Example setup here:
>
>
> https://github.com/timgrossmann/InstaPy/commit/afd968dfa1ce1141456a207484d35f2766d5916b
>
> the app:
>
> https://github.com/marketplace/stale
>
> (c) someone scan through the first-time closure proposal list and
> manually update any which seem deserving of continued life.
>
>
> Closed-as-stale issues don't vanish, they are still there to be browsed
> as needed...
>
> ___
> Scons-dev mailing list
> Scons-dev@scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
[Scons-dev] bug prune
Just to pull some thoughts together:
there are currently 679 open scons issues on github.
That number drops to 92 if you select only ones which have had a
modification since the big migration from tigris. Try this query:
is:issue is:open updated:>=2018-02-10
or as a link:
https://github.com/SCons/scons/issues?utf8=%E2%9C%93=is%3Aissue+is%3Aopen+updated%3A%3E%3D2018-02-10+
I'm a relative newcomer around here, but I don't see the value of
showing a ton of historical bugs that aren't being worked on; the newly
filed ones don't even get a lot of attention - there just isn't a big
scons team at this point and numerically most current contributors have
a specific motivation ("itch to scratch" as it were) rather than the
ability to just generally work on bugs. To provide more visible focus
there's already been some discussion of a bug prune.
My suggestion is this:
(a) close all open tigris bugs with a message that includes these items:
* bug is now tracked on github [link]
* bugs which have not had activity in 18 months are going to be closed
(it doesn't have to be 18, but that was the cutover time)
* we understand readers of this issue might not see messages from
github, so if you want to keep this issue alive, make a comment - any
comment - on the corresponding github issue.
(b) fire up a bot to mark inactive github issues with a tag, and
configure suitably. Looks like there's an app in the github marketplace
that is free so setup is just a YAML file. Example setup here:
https://github.com/timgrossmann/InstaPy/commit/afd968dfa1ce1141456a207484d35f2766d5916b
the app:
https://github.com/marketplace/stale
(c) someone scan through the first-time closure proposal list and
manually update any which seem deserving of continued life.
Closed-as-stale issues don't vanish, they are still there to be browsed
as needed...
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev
