Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Sun, 2018-07-22 at 23:35 +0800, anatoly techtonik wrote:
> 
[…]
> Just a reminder that mindless do-ocracy is the best way to kill
> backward
> compatibility and lose user base. From the other side, it always
> possible to
> fork away something like waf. :)

That's why I mentioned Apache. As Jason has pointed out, there is a
formal structure to release, and hence testing, and big decision making
in general. The system is actually a good one – even though I have
many, many reservations about The Apache Way.

What's Waf's traction/market penetration like?

If one is to consider competitors to SCons, Meson is the threat.

-- 
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] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Sun, 2018-07-22 at 16:38 +, Jason Kenny wrote:
> I work on a Apache process. The point of the process is to create
> community. We have people vote on a release or process that range
> from devs , ops to users. The goal is to not break stuff and make
> something people want to use. 

There is a lot wrong with the whole Apache system, but releasing is not
one of them. Since Apache Groovy has had to stick to Apache release
rules, releases have always been much more stable with fewer
regressions.

> The project I work on we test on ever platform with different
> compilers. We only cut a platform when it falls off the supported
> list. Honestly most of the test failure seem come from "older"
> platforms when we try to add something new. Having the testing for
> these system make sure we don't break on the system and for our
> users. 
> 
> There is also a voting system used with "negative" votes that is used
> to prevent stuff from happening. It is often used by Ops people to
> say that they tested something and it breaks. Don't release. The
> community works at the point to figure out how to address the issue
> and go forward with a new vote. 

The +1, 0, -1 system has it's faults, but the explicitness of the
voting system is a good thing. That there is a quorum required for a
vote to win is a very good thing.

-- 
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] Should we remove python 3.5 from our CI tests

[Bill Deegan]

I have a collection of scripts for building various python versions on
ubuntu & centos.
Please feel free to use:
https://github.com/bdbaddog/python_build_scripts

Pull requests welcome.
I suppose I could move to scons, but these aren't just for scons.

-Bill

On Sun, Jul 22, 2018 at 8:39 AM, anatoly techtonik 
wrote:

> On Sat, Jul 21, 2018 at 4:12 AM Jonathon Reinhart
>  wrote:
> >
> > I think SCons would be making a serious mistake if it dropped support
> > for Python 3.5. Just because the distro is using an older version of
> > SCons, doesn't mean that SCons shouldn't support the latest version of
> > Python available on the system.
> >
> > This is particularly troublesome for me as I consider putting together
> > a new build image, based on Debian 9, but with latest SCons installed
> > from source.
>
> Forgot to add that that sounds valid reason. I guess installing never
> Python
> on older Debian is just too cumbersome.
> --
> anatoly t.
> ___
> 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] Should we remove python 3.5 from our CI tests

[Jason Kenny]

I work on a Apache process. The point of the process is to create community. We 
have people vote on a release or process that range from devs , ops to users. 
The goal is to not break stuff and make something people want to use. 

The project I work on we test on ever platform with different compilers. We 
only cut a platform when it falls off the supported list. Honestly most of the 
test failure seem come from "older" platforms when we try to add something new. 
Having the testing for these system make sure we don't break on the system and 
for our users. 

There is also a voting system used with "negative" votes that is used to 
prevent stuff from happening. It is often used by Ops people to say that they 
tested something and it breaks. Don't release. The community works at the point 
to figure out how to address the issue and go forward with a new vote. 

Jason

-Original Message-
From: Scons-dev  On Behalf Of anatoly techtonik
Sent: Sunday, July 22, 2018 10:36 AM
To: SCons Development 
Subject: Re: [Scons-dev] Should we remove python 3.5 from our CI tests

On Sun, Jul 22, 2018 at 7:39 PM Russel Winder  wrote:
>
> On Sat, 2018-07-21 at 13:54 -0700, Bill Deegan wrote:
> > […]
> >
> > Regardless I think we've covered the bases in this discussion and 
> > let's revisit Jan 2019 to see what makes sense.
> > The thoughtful discussion is much appreciated!
>
> In the end, SCons development must be a do-ocracy (an Apache concept I 
> believe), in that those who actually do development stuff have vastly 
> more votes than those who watch development. Obviously those who use 
> and report back also must have a voice.

Just a reminder that mindless do-ocracy is the best way to kill backward 
compatibility and lose user base. From the other side, it always possible to 
fork away something like waf. :)
--
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist2.pair.net%2Fmailman%2Flistinfo%2Fscons-dev=02%7C01%7C%7Cbdd1796306504524983a08d5efe9069f%7C84df9e7fe9f640afb435%7C1%7C0%7C636678706466675123=38j0eLnS3pXoLzZtYmEXw1h3yNCFKdmOTzHZAcRRSJo%3D=0
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[anatoly techtonik]

On Sat, Jul 21, 2018 at 4:12 AM Jonathon Reinhart
 wrote:
>
> I think SCons would be making a serious mistake if it dropped support
> for Python 3.5. Just because the distro is using an older version of
> SCons, doesn't mean that SCons shouldn't support the latest version of
> Python available on the system.
>
> This is particularly troublesome for me as I consider putting together
> a new build image, based on Debian 9, but with latest SCons installed
> from source.

Forgot to add that that sounds valid reason. I guess installing never Python
on older Debian is just too cumbersome.
-- 
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[anatoly techtonik]

On Sun, Jul 22, 2018 at 7:39 PM Russel Winder  wrote:
>
> On Sat, 2018-07-21 at 13:54 -0700, Bill Deegan wrote:
> > […]
> >
> > Regardless I think we've covered the bases in this discussion and
> > let's
> > revisit Jan 2019 to see what makes sense.
> > The thoughtful discussion is much appreciated!
>
> In the end, SCons development must be a do-ocracy (an Apache concept I
> believe), in that those who actually do development stuff have vastly
> more votes than those who watch development. Obviously those who use
> and report back also must have a voice.

Just a reminder that mindless do-ocracy is the best way to kill backward
compatibility and lose user base. From the other side, it always possible to
fork away something like waf. :)
-- 
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Sat, 2018-07-21 at 14:22 +0200, Dirk Baechle wrote:
> […]
> Side note: at work (ATC context) I'm still stuck to Python 2.6 and
> SCons 2.4-1 IIRC, under SLES11 SP2. :)
> 

Sounds like luxury compared to the Prague ATC system.

-- 
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] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Sat, 2018-07-21 at 13:54 -0700, Bill Deegan wrote:
> […]
> 
> Regardless I think we've covered the bases in this discussion and
> let's
> revisit Jan 2019 to see what makes sense.
> The thoughtful discussion is much appreciated!

In the end, SCons development must be a do-ocracy (an Apache concept I
believe), in that those who actually do development stuff have vastly
more votes than those who watch development. Obviously those who use
and report back also must have a voice.

-- 
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] Should we remove python 3.5 from our CI tests

[anatoly techtonik]

On Sat, Jul 21, 2018 at 7:18 PM Gary Oberbrunner  wrote:
>
> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
> Most likely through (at least) the end of 2018.
>
>
> Yes, absolutely. SCons is used by lots of people on older legacy systems. 
> IMHO it is and needs to be a solid, reliable build tool, not (just) a 
> leading-edge dev tool.

Speaking of which - what is the current code coverage?
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Bill Deegan]

While neither windows nor MacOS include SCons, there are defacto package
managers for both:
Windows: Chocolatey - no scons, but multiple python versions
MacOS: macports and homebrew (both include scons and multiple python
versions

Thus far we're not having issues with CI running on 2.7.x, 3.5.x, 3.6.x,
(and now) 3.7.x

For those who haven't been around quite as long, SCons used to support back
to Python 1.5.7 and it took some convincing to get the developers (who
included myself and I was a proponent) to move forward.  I think we moved
first to 2.2, then 2.4, then 2.5, then 2.7.x & 3.5+.

At this point the burden of maintaining our current Python support isn't to
high so no need to start dropping versions of python still in wide usage
and still supported by Python.org..

Mats - As an aside I currently have Coverity running for a client via CI.
(Its either gotten faster or machines have or both, years ago the coverity
build on 3.3M line c/c++ project was 29 hours, and we still ran it via
CI).  Both in their own Coverity builder.

Regardless I think we've covered the bases in this discussion and let's
revisit Jan 2019 to see what makes sense.
The thoughtful discussion is much appreciated!

If we found Python 3.x provided some significant performance advantage that
we could only get by dropping older versions that might be compelling.

-Bill


On Sat, Jul 21, 2018 at 11:56 AM, Mats Wichmann  wrote:

>
> >> If the model is "support whatever is supported in active Linux
> >> distrubtions", that's a valid point. In fact, by that measure, since
> >> long-term distributions like RHEL7 and Ubuntu 14.04 use 3.4, that
> >> should
> >> be on the support/CI list as well.
> >
> > The distros package SCons and well as Python, so there doesn't seem to
> > be a problem.
> >
> >>> Are you going to drop Python 2 support too?
> >>
> >> 2.7 is still a supported version, even at python.org.
>
> There aren't really any easy answers.  I think I expressed earlier
> support for dropping CI support for 3.5, but...
>
> scons is a tool used to build projects, not really a part of the
> projects. "Users" become interested in scons itself when there's
> something they can't do with scons, so they want a new version that
> improves that situation (okay, speaking for myself :)  Otherwise,
> changing versions aren't very interesting to them.
>
> obviously a buildsystem has to do more than work flawlessly on bleeding
> edge systems a developer may be running "at his desk". it also has to
> work on external environments that may not be so up to date - QA teams,
> auto-provisioned CI infrastructure, etc.  In fact "not so up to date"
> can be surprisingly old - I think people have already mentioned here
> that there are "official" setups that default to Ubuntu 12.04 (which,
> even as an LTS, is officially out of support); SLES and RHEL and CentOS
> systems that are a half-decade or more out of date, etc.  One of the
> setups in the CI system we use is pegged to scons 2.1.0 because that's
> the available rpm package from the official source used for provisioning
> it.
>
> As long as the builder gets its Python and scons from the same place
> (Linux distro packaging), nothing is too likely to break unexpectedly;
> you can count on those being tested together. But other builders don't
> necessarily have a consistent source - Windows doesn't include either
> Python nor scons; MacOS has a Python but not scons, etc. So those have
> to be provisioned up from an external source and that may mean there are
> occasional surprises if those sources move along.  In some (most?) cases
> you can peg your scons to a version; if that is not done, problems.
>
> But can't support a matrix of everything.  I think many "free for open
> source projects" CI systems tend to start asking for money if you try to
> throw too many combinations at them.  At one point we wanted to
> integrate a Coverity run into our CI system, but that one severely
> limits how many scans-per-time-period you can submit.  So the idea of
> each scons version having a minimum and maximum Python version, and
> those are the versions that are part of CI, makes sense to me.
>
>
>
> ___
> 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] Should we remove python 3.5 from our CI tests

[Mats Wichmann]

>> If the model is "support whatever is supported in active Linux
>> distrubtions", that's a valid point. In fact, by that measure, since
>> long-term distributions like RHEL7 and Ubuntu 14.04 use 3.4, that
>> should
>> be on the support/CI list as well.
> 
> The distros package SCons and well as Python, so there doesn't seem to
> be a problem.
> 
>>> Are you going to drop Python 2 support too?
>>
>> 2.7 is still a supported version, even at python.org.

There aren't really any easy answers.  I think I expressed earlier
support for dropping CI support for 3.5, but...

scons is a tool used to build projects, not really a part of the
projects. "Users" become interested in scons itself when there's
something they can't do with scons, so they want a new version that
improves that situation (okay, speaking for myself :)  Otherwise,
changing versions aren't very interesting to them.

obviously a buildsystem has to do more than work flawlessly on bleeding
edge systems a developer may be running "at his desk". it also has to
work on external environments that may not be so up to date - QA teams,
auto-provisioned CI infrastructure, etc.  In fact "not so up to date"
can be surprisingly old - I think people have already mentioned here
that there are "official" setups that default to Ubuntu 12.04 (which,
even as an LTS, is officially out of support); SLES and RHEL and CentOS
systems that are a half-decade or more out of date, etc.  One of the
setups in the CI system we use is pegged to scons 2.1.0 because that's
the available rpm package from the official source used for provisioning it.

As long as the builder gets its Python and scons from the same place
(Linux distro packaging), nothing is too likely to break unexpectedly;
you can count on those being tested together. But other builders don't
necessarily have a consistent source - Windows doesn't include either
Python nor scons; MacOS has a Python but not scons, etc. So those have
to be provisioned up from an external source and that may mean there are
occasional surprises if those sources move along.  In some (most?) cases
you can peg your scons to a version; if that is not done, problems.

But can't support a matrix of everything.  I think many "free for open
source projects" CI systems tend to start asking for money if you try to
throw too many combinations at them.  At one point we wanted to
integrate a Coverity run into our CI system, but that one severely
limits how many scans-per-time-period you can submit.  So the idea of
each scons version having a minimum and maximum Python version, and
those are the versions that are part of CI, makes sense to me.



___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Jason Kenny]

I would suggest if you want to drop versions of python to test that we at the 
minimum test:


  1.  Lowest version of python 2 we support
  2.  High version of python 2 we support
  3.  Lowest version of python 3 we support
  4.  Highest stable version of python 3 we support

We would want to test others versions because of some behavior it shows that 
breaks something, or because we want more coverage for finding something.

My personal option is that testing more if it cheap to do so, is always better. 
It never hurts and can find unexpected issues.
At the very least test the ranges. Hope everything else in the middle will be 
fine… well at least until one knows better. Then add that to the testing until 
it falls off the minimum supported version.

Jason

From: Scons-dev  On Behalf Of Bill Deegan
Sent: Friday, July 20, 2018 10:20 PM
To: SCons developer list 
Subject: Re: [Scons-dev] Should we remove python 3.5 from our CI tests

Pretty certain Gary's with me in saying,
SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
Most likely through (at least) the end of 2018.

I know many who actively participate in SCons community live on the leading 
edge of OS and Python releases but many users do not.
Also, there are still some rough edges to our Python 3 support. Until it's rock 
solid (and no one has found an issue for a while), dropping py 2.7 would be 
unwise.


-Bill
SCons Project Co-Manager.

On Fri, Jul 20, 2018 at 4:11 PM, Jonathon Reinhart 
mailto:jonathon.reinh...@gmail.com>> wrote:
> True but who uses Debian Stable for anything relating to software
> development, it is a server distribution.

I'm not sure where you got the idea that Debian is a "server
distribution". Lots of people use Debian as a desktop OS, and my team
uses Debian for software development.

I think SCons would be making a serious mistake if it dropped support
for Python 3.5. Just because the distro is using an older version of
SCons, doesn't mean that SCons shouldn't support the latest version of
Python available on the system.

This is particularly troublesome for me as I consider putting together
a new build image, based on Debian 9, but with latest SCons installed
from source.

I'm all for cleaning up old cruft, but it seems like removing support
for a version of Python that's less than 3 years old seems a bit
aggressive.
___
Scons-dev mailing list
Scons-dev@scons.org<mailto:Scons-dev@scons.org>
https://pairlist2.pair.net/mailman/listinfo/scons-dev<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist2.pair.net%2Fmailman%2Flistinfo%2Fscons-dev=02%7C01%7C%7C30f2ab5440db4846466d08d5eeb9e544%7C84df9e7fe9f640afb435%7C1%7C0%7C63667740453788=t84s%2FlzSszFu1%2FKvFcO4FkZ9pFUQAgAkmaCq0GTtYjI%3D=0>

___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Dirk Baechle]

Hi there, 

(yes, I'm still alive ;) ) +1 from me for, at least trying to provide, some 
backward compatibility to Python 2.7.x. As long as the impact on current 
development is low, we should try to bring the new SCons stuff also to people 
using older Python distros.

Side note: at work (ATC context) I'm still stuck to Python 2.6 and SCons 2.4-1 
IIRC, under SLES11 SP2. :)

Best regards, 

Dirk


Am 21. Juli 2018 13:43:07 MESZ schrieb Gary Oberbrunner :
>Russel says:
>
>Python 2 is the millstone for SCons 3.
>
>I've been using 3.6 for all recent projects and loving it (async,
>f-strings, etc.), but what weight are we really carrying by supporting
>2.x?
>Seems to me like most 3.6 features can be detected at runtime while
>still
>keeping back compat without too much extra work. But I may be missing
>something.
>
>-- Gary
>
>On Sat, Jul 21, 2018 at 7:37 AM Russel Winder 
>wrote:
>
>> On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
>> > Pretty certain Gary's with me in saying,
>> > SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
>> > releases.
>> > Most likely through (at least) the end of 2018.
>>
>> You can add me to agreeing with that.
>>
>> > I know many who actively participate in SCons community live on the
>> > leading
>> > edge of OS and Python releases but many users do not.
>> > Also, there are still some rough edges to our Python 3 support.
>Until
>> > it's
>> > rock solid (and no one has found an issue for a while), dropping py
>> > 2.7
>> > would be unwise.
>>
>> I see your finger pointing at me. :-)
>>
>> We have had not dissimilar maintenance debates in the Apache Groovy
>> community, especially now JDK is updated every 6 months instead of
>> every 6 years. Clearly there is a need to support people using
>ancient
>> three year old systems. Debian Stable and Ubuntu LTS really set the
>> timescales here, and the Python versions. Except that Travis-CI
>appears
>> to think using the most ancient Ubuntu LTS they can is a good thing.
>>
>> But then come the issues at the heart of the matter: If people are
>> using three or five year old platforms, will they be using the very
>> latest version of SCons? If they want the very latest SCons why can't
>> they install the very latest Python? If they are happy with the three
>> year old Python will they actually be happy with the three year old
>> SCons? If a distribution provides Python and SCons why is there any
>> interest in them updating anything?
>>
>> Groovy used to have a "we must be totally backward compatible"
>> obsession that was over the top, especially for me. Over the last
>year
>> the policy has changed towards something much better, and which has
>> allowed Groovy to progress much better in a highly dynamic world.
>>
>> OK so Java has the big difference that you distribute compiled
>> artefacts and there are only link time issues, whereas Python is
>> distributed as source so everything is compile time issues. But the
>> Groovy team have now begun to accept that "backward compatibility"
>can
>> be taken too far. For each major version of Groovy a lower limit is
>now
>> set and if people are not prepared to update their Java, then they
>have
>> to use the last version of Groovy that works with that version of
>Java.
>>
>> Python 2 is the millstone for SCons 3. The question is whether there
>> will be a 2.7.16 or whether 2.7.15 is really the last version. Also
>> will an organisation break ranks with PSF policy and pick up Python
>2.7
>> and keep it going? Would that matter for SCons?
>>
>> I can fully understand sticking with 3.5 at this time, but SCons
>> versions must be allowed to change the minimum Python version. Should
>> SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
>> then people not on Python 3.6 simply stay with SCons 3.0.X.
>>
>> For me this is all about consistency: you can't demand cutting edge
>> SCons unless you are prepared to use cutting edge Python.
>>
>> --
>> 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
>>
>
>
>-- 
>Gary

-- 
Sent from my Android with K-9 Mail.___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Gary Oberbrunner]

Russel says:

Python 2 is the millstone for SCons 3.

I've been using 3.6 for all recent projects and loving it (async,
f-strings, etc.), but what weight are we really carrying by supporting 2.x?
Seems to me like most 3.6 features can be detected at runtime while still
keeping back compat without too much extra work. But I may be missing
something.

-- Gary

On Sat, Jul 21, 2018 at 7:37 AM Russel Winder  wrote:

> On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
> > Pretty certain Gary's with me in saying,
> > SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
> > releases.
> > Most likely through (at least) the end of 2018.
>
> You can add me to agreeing with that.
>
> > I know many who actively participate in SCons community live on the
> > leading
> > edge of OS and Python releases but many users do not.
> > Also, there are still some rough edges to our Python 3 support. Until
> > it's
> > rock solid (and no one has found an issue for a while), dropping py
> > 2.7
> > would be unwise.
>
> I see your finger pointing at me. :-)
>
> We have had not dissimilar maintenance debates in the Apache Groovy
> community, especially now JDK is updated every 6 months instead of
> every 6 years. Clearly there is a need to support people using ancient
> three year old systems. Debian Stable and Ubuntu LTS really set the
> timescales here, and the Python versions. Except that Travis-CI appears
> to think using the most ancient Ubuntu LTS they can is a good thing.
>
> But then come the issues at the heart of the matter: If people are
> using three or five year old platforms, will they be using the very
> latest version of SCons? If they want the very latest SCons why can't
> they install the very latest Python? If they are happy with the three
> year old Python will they actually be happy with the three year old
> SCons? If a distribution provides Python and SCons why is there any
> interest in them updating anything?
>
> Groovy used to have a "we must be totally backward compatible"
> obsession that was over the top, especially for me. Over the last year
> the policy has changed towards something much better, and which has
> allowed Groovy to progress much better in a highly dynamic world.
>
> OK so Java has the big difference that you distribute compiled
> artefacts and there are only link time issues, whereas Python is
> distributed as source so everything is compile time issues. But the
> Groovy team have now begun to accept that "backward compatibility" can
> be taken too far. For each major version of Groovy a lower limit is now
> set and if people are not prepared to update their Java, then they have
> to use the last version of Groovy that works with that version of Java.
>
> Python 2 is the millstone for SCons 3. The question is whether there
> will be a 2.7.16 or whether 2.7.15 is really the last version. Also
> will an organisation break ranks with PSF policy and pick up Python 2.7
> and keep it going? Would that matter for SCons?
>
> I can fully understand sticking with 3.5 at this time, but SCons
> versions must be allowed to change the minimum Python version. Should
> SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
> then people not on Python 3.6 simply stay with SCons 3.0.X.
>
> For me this is all about consistency: you can't demand cutting edge
> SCons unless you are prepared to use cutting edge Python.
>
> --
> 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
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Fri, 2018-05-25 at 15:57 -0600, Mats Wichmann wrote:
> On 05/25/2018 03:44 PM, Bill Deegan wrote:
> > We need to test every version we say we support.
> > That's the purpose of the CI...
> 
> well, sure.
> 
> but Python itself pretty much only supports the last two 3.x versions
> (there may be some emergency bugfixes later than that, if I recall
> the
> most recent release PEP suggested a 5-year sunset even for that which
> would take 3.5 out through 2019).

Which fits with the statement of no change till at least end of 2018.

> 
> And Jonathon:
> 
> > No way. Distros (e.g. Debian 9) package Python 3.5.
> 
> If the model is "support whatever is supported in active Linux
> distrubtions", that's a valid point. In fact, by that measure, since
> long-term distributions like RHEL7 and Ubuntu 14.04 use 3.4, that
> should
> be on the support/CI list as well.

The distros package SCons and well as Python, so there doesn't seem to
be a problem.

> > Are you going to drop Python 2 support too?
> 
> 2.7 is still a supported version, even at python.org.

Not entirely true, there is 2.7.15, but unless there is a 2.7.16 one
cannot claim it is being supported. PSF have basically returned to the
position that Python 2 has gone end of life.

-- 
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] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Fri, 2018-07-20 at 23:20 -0400, Bill Deegan wrote:
> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x
> releases.
> Most likely through (at least) the end of 2018.

You can add me to agreeing with that.

> I know many who actively participate in SCons community live on the
> leading
> edge of OS and Python releases but many users do not.
> Also, there are still some rough edges to our Python 3 support. Until
> it's
> rock solid (and no one has found an issue for a while), dropping py
> 2.7
> would be unwise.

I see your finger pointing at me. :-)

We have had not dissimilar maintenance debates in the Apache Groovy
community, especially now JDK is updated every 6 months instead of
every 6 years. Clearly there is a need to support people using ancient
three year old systems. Debian Stable and Ubuntu LTS really set the
timescales here, and the Python versions. Except that Travis-CI appears
to think using the most ancient Ubuntu LTS they can is a good thing.

But then come the issues at the heart of the matter: If people are
using three or five year old platforms, will they be using the very
latest version of SCons? If they want the very latest SCons why can't
they install the very latest Python? If they are happy with the three
year old Python will they actually be happy with the three year old
SCons? If a distribution provides Python and SCons why is there any
interest in them updating anything?

Groovy used to have a "we must be totally backward compatible"
obsession that was over the top, especially for me. Over the last year
the policy has changed towards something much better, and which has
allowed Groovy to progress much better in a highly dynamic world.

OK so Java has the big difference that you distribute compiled
artefacts and there are only link time issues, whereas Python is
distributed as source so everything is compile time issues. But the
Groovy team have now begun to accept that "backward compatibility" can
be taken too far. For each major version of Groovy a lower limit is now
set and if people are not prepared to update their Java, then they have
to use the last version of Groovy that works with that version of Java.

Python 2 is the millstone for SCons 3. The question is whether there
will be a 2.7.16 or whether 2.7.15 is really the last version. Also
will an organisation break ranks with PSF policy and pick up Python 2.7
and keep it going? Would that matter for SCons?

I can fully understand sticking with 3.5 at this time, but SCons
versions must be allowed to change the minimum Python version. Should
SCons 3.1 require Python 3.6 and drop support for Python 2.7? If yes
then people not on Python 3.6 simply stay with SCons 3.0.X.

For me this is all about consistency: you can't demand cutting edge
SCons unless you are prepared to use cutting edge Python.

-- 
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] Should we remove python 3.5 from our CI tests

[Gary Oberbrunner]

Pretty certain Gary's with me in saying,
SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
Most likely through (at least) the end of 2018.


Yes, absolutely. SCons is used by lots of people on older legacy systems.
IMHO it is and needs to be a solid, reliable build tool, not (just) a
leading-edge dev tool.

-- Gary


On Fri, Jul 20, 2018 at 11:27 PM Bill Deegan 
wrote:

> Pretty certain Gary's with me in saying,
> SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
> Most likely through (at least) the end of 2018.
>
> I know many who actively participate in SCons community live on the
> leading edge of OS and Python releases but many users do not.
> Also, there are still some rough edges to our Python 3 support. Until it's
> rock solid (and no one has found an issue for a while), dropping py 2.7
> would be unwise.
>
>
> -Bill
> SCons Project Co-Manager.
>
> On Fri, Jul 20, 2018 at 4:11 PM, Jonathon Reinhart <
> jonathon.reinh...@gmail.com> wrote:
>
>> > True but who uses Debian Stable for anything relating to software
>> > development, it is a server distribution.
>>
>> I'm not sure where you got the idea that Debian is a "server
>> distribution". Lots of people use Debian as a desktop OS, and my team
>> uses Debian for software development.
>>
>> I think SCons would be making a serious mistake if it dropped support
>> for Python 3.5. Just because the distro is using an older version of
>> SCons, doesn't mean that SCons shouldn't support the latest version of
>> Python available on the system.
>>
>> This is particularly troublesome for me as I consider putting together
>> a new build image, based on Debian 9, but with latest SCons installed
>> from source.
>>
>> I'm all for cleaning up old cruft, but it seems like removing support
>> for a version of Python that's less than 3 years old seems a bit
>> aggressive.
>> ___
>> 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
>


-- 
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Fri, 2018-07-20 at 16:11 -0400, Jonathon Reinhart wrote:
> > True but who uses Debian Stable for anything relating to software
> > development, it is a server distribution.
> 
> I'm not sure where you got the idea that Debian is a "server
> distribution". Lots of people use Debian as a desktop OS, and my team
> uses Debian for software development.

Debian Stable is an excellent server distribution. All the developers I
know that use Debian use Debian Sid for software development. I use
Debian Sid for all my work, though I dual boot Fedora Rawhide for
testing, I see no positive benefit to using Debian Stable as a work
platform for software development.

> I think SCons would be making a serious mistake if it dropped support
> for Python 3.5. Just because the distro is using an older version of
> SCons, doesn't mean that SCons shouldn't support the latest version
> of
> Python available on the system.

I think I agree with this. If we were talking about 3.4, i'd say drop
it. But 3.5 is a reasonable lower limit at the moment. OK it means not
being able to use some good stuff from 3.6 and 3.7 but that is not
possible anyway if running on 2.7 is required, and a lot of the new
stuff in 3.6 and 3.7 is just trendy rubbish that never should have made
it into the distribution – it should have been packages hosted in PyPI.

> This is particularly troublesome for me as I consider putting
> together
> a new build image, based on Debian 9, but with latest SCons installed
> from source.
> 
> I'm all for cleaning up old cruft, but it seems like removing support
> for a version of Python that's less than 3 years old seems a bit
> aggressive.

I agree. In a couple of years when we have 3.8 or 3.9 I'll be all for
dropping 3.5 and 2.7 and refactoring the codebase to 3.6.

-- 
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] Should we remove python 3.5 from our CI tests

[Bill Deegan]

Pretty certain Gary's with me in saying,
SCons will support Python 2.7 and 3.5+ in (at least) the 3.x releases.
Most likely through (at least) the end of 2018.

I know many who actively participate in SCons community live on the leading
edge of OS and Python releases but many users do not.
Also, there are still some rough edges to our Python 3 support. Until it's
rock solid (and no one has found an issue for a while), dropping py 2.7
would be unwise.


-Bill
SCons Project Co-Manager.

On Fri, Jul 20, 2018 at 4:11 PM, Jonathon Reinhart <
jonathon.reinh...@gmail.com> wrote:

> > True but who uses Debian Stable for anything relating to software
> > development, it is a server distribution.
>
> I'm not sure where you got the idea that Debian is a "server
> distribution". Lots of people use Debian as a desktop OS, and my team
> uses Debian for software development.
>
> I think SCons would be making a serious mistake if it dropped support
> for Python 3.5. Just because the distro is using an older version of
> SCons, doesn't mean that SCons shouldn't support the latest version of
> Python available on the system.
>
> This is particularly troublesome for me as I consider putting together
> a new build image, based on Debian 9, but with latest SCons installed
> from source.
>
> I'm all for cleaning up old cruft, but it seems like removing support
> for a version of Python that's less than 3 years old seems a bit
> aggressive.
> ___
> 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] Should we remove python 3.5 from our CI tests

[Jonathon Reinhart]

> True but who uses Debian Stable for anything relating to software
> development, it is a server distribution.

I'm not sure where you got the idea that Debian is a "server
distribution". Lots of people use Debian as a desktop OS, and my team
uses Debian for software development.

I think SCons would be making a serious mistake if it dropped support
for Python 3.5. Just because the distro is using an older version of
SCons, doesn't mean that SCons shouldn't support the latest version of
Python available on the system.

This is particularly troublesome for me as I consider putting together
a new build image, based on Debian 9, but with latest SCons installed
from source.

I'm all for cleaning up old cruft, but it seems like removing support
for a version of Python that's less than 3 years old seems a bit
aggressive.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Fri, 2018-07-20 at 20:02 +0800, anatoly techtonik wrote:
> […]
> 
> But the question was about Debian 9. Anyway 10th ships with Python
> 3.6
> https://packages.debian.org/buster/python3 and SCons 3 with python2
> as
> dependency, which is most unfortunate, because SConstructs will start
> to break not when SCons switched to next major version, but when next
> Debian hideously updates dependency to python3. =/

True but who uses Debian Stable for anything relating to software
development, it is a server distribution.

If SCons 3 has an explicit Python 2 only dependency that is wrong and
should be raised as a bug, it should depend on Python 3 or if that
fails Python 2.

Fedora Rawhide is most of the way to removing Python 2, but Debian
hasn't really properly started the campaign.

> But at least Python 3.5 can be forgotten.
> 
> > +1 for dropping 2.7 ;-)
> 
> 2.7 +1 == 2.8 =)

That will only happen if someone forks Python 2, PSF are never going to
do that.

-- 
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] Should we remove python 3.5 from our CI tests

[anatoly techtonik]

On Fri, Jul 20, 2018 at 6:14 PM Russel Winder  wrote:
>
> On Fri, 2018-07-20 at 16:13 +0800, anatoly techtonik wrote:
> > On Sat, May 26, 2018 at 5:43 AM Jonathon Reinhart
> >  wrote:
> > >
> > > No way. Distros (e.g. Debian 9) package Python 3.5.
> >
> > They are not going to upgrade to SCons 3.x, so it is safe.
> > https://packages.debian.org/stretch/scons
>
> Of course they have already upgraded.
>
> https://packages.debian.org/sid/scons

But the question was about Debian 9. Anyway 10th ships with Python 3.6
https://packages.debian.org/buster/python3 and SCons 3 with python2 as
dependency, which is most unfortunate, because SConstructs will start
to break not when SCons switched to next major version, but when next
Debian hideously updates dependency to python3. =/

But at least Python 3.5 can be forgotten.

> +1 for dropping 2.7 ;-)

2.7 +1 == 2.8 =)
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Russel Winder]

On Fri, 2018-07-20 at 16:13 +0800, anatoly techtonik wrote:
> On Sat, May 26, 2018 at 5:43 AM Jonathon Reinhart
>  wrote:
> > 
> > No way. Distros (e.g. Debian 9) package Python 3.5.
> 
> They are not going to upgrade to SCons 3.x, so it is safe.
> https://packages.debian.org/stretch/scons

Of course they have already upgraded.

https://packages.debian.org/sid/scons

> > > > Downside is longer ci iterations and using more resources from
> > > > the
> > > > generously free ci platforms.
> > > 
> > > I'd vote - once 3.7 is out (that likely next month, no?), 3.5
> > > should be
> > > dropped. Can't test every version.
> 
> +1 for dropping 3.5. 3.7 has some nifty features, but that maybe
> incompatible with 2.7

+1 for dropping 2.7 ;-)

-- 
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] Should we remove python 3.5 from our CI tests

[anatoly techtonik]

On Sat, May 26, 2018 at 5:43 AM Jonathon Reinhart
 wrote:
>
> No way. Distros (e.g. Debian 9) package Python 3.5.

They are not going to upgrade to SCons 3.x, so it is safe.
https://packages.debian.org/stretch/scons

> >> Downside is longer ci iterations and using more resources from the
> >> generously free ci platforms.
> >
> > I'd vote - once 3.7 is out (that likely next month, no?), 3.5 should be
> > dropped. Can't test every version.

+1 for dropping 3.5. 3.7 has some nifty features, but that maybe
incompatible with 2.7
-- 
anatoly t.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Mats Wichmann]

On 05/25/2018 03:44 PM, Bill Deegan wrote:
> We need to test every version we say we support.
> That's the purpose of the CI...

well, sure.

but Python itself pretty much only supports the last two 3.x versions
(there may be some emergency bugfixes later than that, if I recall the
most recent release PEP suggested a 5-year sunset even for that which
would take 3.5 out through 2019).


And Jonathon:

> No way. Distros (e.g. Debian 9) package Python 3.5.

If the model is "support whatever is supported in active Linux
distrubtions", that's a valid point. In fact, by that measure, since
long-term distributions like RHEL7 and Ubuntu 14.04 use 3.4, that should
be on the support/CI list as well.

> Are you going to drop Python 2 support too?

2.7 is still a supported version, even at python.org.


___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Should we remove python 3.5 from our CI tests

[Bill Deegan]

Though it's likely not worth testing both 32 and 64 bit pythons on windows.

-Bill

On Fri, May 25, 2018 at 4:44 PM, Bill Deegan 
wrote:

> We need to test every version we say we support.
> That's the purpose of the CI...
>
> On Fri, May 25, 2018 at 4:10 PM, Mats Wichmann  wrote:
>
>> On 05/25/2018 02:59 PM, Daniel Moody wrote:
>> > Opening discussion to remove 3.5 from the CI tests.
>> >
>> > Is there any reason we need 3.5 specifically?
>> > 3.6 has been out for a while and is pretty stable.
>> >
>> > It's automated ci so there isn't much effort in keeping it part of the
>> > tests, but we should only do it if there is reason.
>> >
>> > Downside is longer ci iterations and using more resources from the
>> > generously free ci platforms.
>>
>> I'd vote - once 3.7 is out (that likely next month, no?), 3.5 should be
>> dropped. Can't test every version.
>> ___
>> 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] Should we remove python 3.5 from our CI tests

[Bill Deegan]

We need to test every version we say we support.
That's the purpose of the CI...

On Fri, May 25, 2018 at 4:10 PM, Mats Wichmann  wrote:

> On 05/25/2018 02:59 PM, Daniel Moody wrote:
> > Opening discussion to remove 3.5 from the CI tests.
> >
> > Is there any reason we need 3.5 specifically?
> > 3.6 has been out for a while and is pretty stable.
> >
> > It's automated ci so there isn't much effort in keeping it part of the
> > tests, but we should only do it if there is reason.
> >
> > Downside is longer ci iterations and using more resources from the
> > generously free ci platforms.
>
> I'd vote - once 3.7 is out (that likely next month, no?), 3.5 should be
> dropped. Can't test every version.
> ___
> 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] Should we remove python 3.5 from our CI tests

[Jonathon Reinhart]

No way. Distros (e.g. Debian 9) package Python 3.5.

Are you going to drop Python 2 support too?

It's really not that big of a deal to test each minor version. Plenty
of open source software far less important than SCons does it.

On Fri, May 25, 2018 at 5:10 PM, Mats Wichmann  wrote:
> On 05/25/2018 02:59 PM, Daniel Moody wrote:
>> Opening discussion to remove 3.5 from the CI tests.
>>
>> Is there any reason we need 3.5 specifically?
>> 3.6 has been out for a while and is pretty stable.
>>
>> It's automated ci so there isn't much effort in keeping it part of the
>> tests, but we should only do it if there is reason.
>>
>> Downside is longer ci iterations and using more resources from the
>> generously free ci platforms.
>
> I'd vote - once 3.7 is out (that likely next month, no?), 3.5 should be
> dropped. Can't test every version.
> ___
> 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] Should we remove python 3.5 from our CI tests

[Mats Wichmann]

On 05/25/2018 02:59 PM, Daniel Moody wrote:
> Opening discussion to remove 3.5 from the CI tests.
> 
> Is there any reason we need 3.5 specifically?
> 3.6 has been out for a while and is pretty stable.
> 
> It's automated ci so there isn't much effort in keeping it part of the
> tests, but we should only do it if there is reason.
> 
> Downside is longer ci iterations and using more resources from the
> generously free ci platforms.

I'd vote - once 3.7 is out (that likely next month, no?), 3.5 should be
dropped. Can't test every version.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

[Scons-dev] Should we remove python 3.5 from our CI tests

[Daniel Moody]

Opening discussion to remove 3.5 from the CI tests.

Is there any reason we need 3.5 specifically?
3.6 has been out for a while and is pretty stable.

It's automated ci so there isn't much effort in keeping it part of the
tests, but we should only do it if there is reason.

Downside is longer ci iterations and using more resources from the
generously free ci platforms.
___
Scons-dev mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev