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
[Scons-dev] Twitter poll on dropping py27 support
https://twitter.com/SConsProject/status/1169688929903230976?s=20 ___ 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] scons: path-like objects
On Wed, 2019-09-04 at 11:29 -0600, Mats Wichmann wrote: > does anyone think it is important to examine scons for support of Python > path-like objects? > As soon as SCons ditches Python 2 support then reviewing all the path handling to perhaps use pathlib rather than strings would be a good idea. Of course SConstruct files can already use pathlib, I know I do. -- 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 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
