Re: [Scons-dev] Python3 activity

[Dirk Bächle]

Hi Vasily,

On 25.01.2016 21:39, Vasily wrote:

Any answer to my question about the place and approach for stubprocess to live 
in?

Thanks,
Vasily

16 янв. 2016 г. 0:17 пользователь "Vasily" mailto:just.one@yandex.ru>> написал:

I have started looking into the docs for integrating stubprocess in there.

My current thoughts are to put it as a separate file next to posix.py in 
"Platform", any objections to this approach? Should I
maybe put it to "compat"?



sorry for not coming back to you about this question. The "platform" folder is fine, just put the new module file there. Thanks a 
lot for working on this!


Best regards,

Dirk

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

Re: [Scons-dev] Python3 activity

[William Blevins]

I would personally make it a separate file. I'm a very OOP-centric geek.

V/R,
William

On Mon, Jan 25, 2016 at 8:39 PM, Vasily  wrote:

> Any answer to my question about the place and approach for stubprocess to
> live in?
>
> Thanks,
> Vasily
> 16 янв. 2016 г. 0:17 пользователь "Vasily" 
> написал:
>
> I have started looking into the docs for integrating stubprocess in there.
>>
>> My current thoughts are to put it as a separate file next to posix.py in
>> "Platform", any objections to this approach? Should I maybe put it to
>> "compat"?
>>
>> Thanks,
>> Vasily
>> 15 янв. 2016 г. 21:05 пользователь "Bill Deegan" <
>> b...@baddogconsulting.com> написал:
>>
>>> I'm not going to merge any pull request for such until 2.5 is out though.
>>>
>>> Is anyone able to work on getting stubprocess logic into 2.5?
>>> If not I'll roll up 2.5 this weekend.
>>>
>>> -Bill
>>>
>>> On Fri, Jan 15, 2016 at 10:04 AM, Bill Deegan >> > wrote:
>>>
 +1.

 I'll see if I can get a python 3.5 buildbot slave up soon.

 -Bill

 On Fri, Jan 15, 2016 at 6:01 AM, William Blevins >>> > wrote:

> +1
>
> On Fri, Jan 15, 2016 at 1:24 PM, Russel Winder 
> wrote:
>
>> Will try to do some more on this over the weekend.
>>
>> I got stuck on the weird os.mkinfo problem (still unsolved) and got a
>> bit distracted by Me TV rewrite ­required to be ready soon so as to
>> watch the 6 Nations games. New DVB-T2 USB sticks arriving tomorrow.
>>
>> On the really up-side, it appears that "futurize -1" is properly
>> idempotent, making it a lot easier to work with than anything
>> previously.
>>
>> Aim is still to get the code-base working properly, i.e passing all
>> tests, as a Python 2.7 program, so that it can then become the default
>> branch. My thinking here is that if we do not have a separate branch,
>> but instead are evolving default to be Python 3 compatible as a Python
>> 2.7 codebase then Python 3 usage will happen faster. The "down side"
>> is
>> that all Python 2 code must be written with Python 3 compliance from
>> merge time on on, this includes all pull requests.
>>
>> --
>> Russel.
>>
>> =
>> Dr Russel Winder  t: +44 20 7585 2200   voip:
>> sip:russel.win...@ekiga.net
>> 41 Buckmaster Roadm: +44 7770 465 077   xmpp:
>> rus...@winder.org.uk
>> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>
>>
>> ___
>> 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 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] Python3 activity

[Vasily]

Any answer to my question about the place and approach for stubprocess to
live in?

Thanks,
Vasily
16 янв. 2016 г. 0:17 пользователь "Vasily"  написал:

> I have started looking into the docs for integrating stubprocess in there.
>
> My current thoughts are to put it as a separate file next to posix.py in
> "Platform", any objections to this approach? Should I maybe put it to
> "compat"?
>
> Thanks,
> Vasily
> 15 янв. 2016 г. 21:05 пользователь "Bill Deegan" <
> b...@baddogconsulting.com> написал:
>
>> I'm not going to merge any pull request for such until 2.5 is out though.
>>
>> Is anyone able to work on getting stubprocess logic into 2.5?
>> If not I'll roll up 2.5 this weekend.
>>
>> -Bill
>>
>> On Fri, Jan 15, 2016 at 10:04 AM, Bill Deegan 
>> wrote:
>>
>>> +1.
>>>
>>> I'll see if I can get a python 3.5 buildbot slave up soon.
>>>
>>> -Bill
>>>
>>> On Fri, Jan 15, 2016 at 6:01 AM, William Blevins 
>>> wrote:
>>>
 +1

 On Fri, Jan 15, 2016 at 1:24 PM, Russel Winder 
 wrote:

> Will try to do some more on this over the weekend.
>
> I got stuck on the weird os.mkinfo problem (still unsolved) and got a
> bit distracted by Me TV rewrite ­required to be ready soon so as to
> watch the 6 Nations games. New DVB-T2 USB sticks arriving tomorrow.
>
> On the really up-side, it appears that "futurize -1" is properly
> idempotent, making it a lot easier to work with than anything
> previously.
>
> Aim is still to get the code-base working properly, i.e passing all
> tests, as a Python 2.7 program, so that it can then become the default
> branch. My thinking here is that if we do not have a separate branch,
> but instead are evolving default to be Python 3 compatible as a Python
> 2.7 codebase then Python 3 usage will happen faster. The "down side" is
> that all Python 2 code must be written with Python 3 compliance from
> merge time on on, this includes all pull requests.
>
> --
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> ___
> 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 mailing list
Scons-dev@scons.org
https://pairlist2.pair.net/mailman/listinfo/scons-dev

Re: [Scons-dev] Python 3 strategy

[Bill Deegan]

+1 what Dirk & Gary said with the following addition.
If you're going to start from default again, then branch to a different
python3 branch "python3-futurize".

Otherwise if someone will take a look at
https://bitbucket.org/scons/scons/pull-requests/298/fix-for-tigris-bug-2622-alwaysbuild-msvc/diff
and approve/decline it, I'll merge that in and get 2.5 release out. Then
default would be open for python 3 efforts.

-Bill

On Mon, Jan 25, 2016 at 1:21 PM, Dirk Bächle  wrote:

> Hi there,
>
> On 25.01.2016 10:39, Russel Winder wrote:
>
>> I am having difficulty making a decision…
>>
>> The earlier Python 3 branch is founded on using six. At the time a good
>> decision. Now however we have agreed that 2.7 is the base version and
>> thus future rather than six is the better tool for Python 3. This
>> brings into doubt the python3-port branch as a good base of operations.
>>
>>
> here's my 2 cents: For me the major point is to have a combined
> Python2.7/3.x version at all, and if you guys (thinking of Russel and
> William right now) get the impression that starting from scratch with
> "futurize" is the better plan...please do so. You're doing the hard work
> towards this goal at the moment, so you should be free to decide how to get
> there, in my opinion.
> And if this means that some users will later on complain about the
> dependency to "futurize", well I'd let it happen...
> I see a greater overall benefit for the project in getting "some work
> done", than in "discussing things to death, due to fear of the unknown". ;)
> I'd second Gary, you might want to have a short look at his change
> sets...and if you still feel like starting from scratch afterwards, just go
> for it.
>
> Best regards,
>
> Dirk
>
>
> ___
> 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] Python 3 strategy

[Dirk Bächle]

Hi there,

On 25.01.2016 10:39, Russel Winder wrote:

I am having difficulty making a decision…

The earlier Python 3 branch is founded on using six. At the time a good
decision. Now however we have agreed that 2.7 is the base version and
thus future rather than six is the better tool for Python 3. This
brings into doubt the python3-port branch as a good base of operations.



here's my 2 cents: For me the major point is to have a combined Python2.7/3.x version at all, and if you guys (thinking of Russel 
and William right now) get the impression that starting from scratch with "futurize" is the better plan...please do so. You're doing 
the hard work towards this goal at the moment, so you should be free to decide how to get there, in my opinion.

And if this means that some users will later on complain about the dependency to 
"futurize", well I'd let it happen...
I see a greater overall benefit for the project in getting "some work done", than in "discussing things to death, due to fear of the 
unknown". ;)
I'd second Gary, you might want to have a short look at his change sets...and if you still feel like starting from scratch 
afterwards, just go for it.


Best regards,

Dirk

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

Re: [Scons-dev] Python 3 strategy

[Tim Jenness]

> On Jan 25, 2016, at 05:29 , William Blevins  wrote:
> 
> 
> 
> On Mon, Jan 25, 2016 at 9:39 AM, Russel Winder  > wrote:
> I am having difficulty making a decision…
> 
> The earlier Python 3 branch is founded on using six. At the time a good
> decision. Now however we have agreed that 2.7 is the base version and
> thus future rather than six is the better tool for Python 3. This
> brings into doubt the python3-port branch as a good base of operations.
> 
> William has done some work changing the python3-port branch, as have I,
> all based on the massive previous work. Despite all this effort I
> wonder if we have the right base to progress further. Maybe we have and
> carry on, but now is the time to stop before much more effort goes in
> if this is not the way forward.
> 
> The alternative is to abandon the current python3-port and start again
> from default based solely on future.
> 
> Instead of having a separate branch, let us work solely on default,
> turning it first into a Python 2.7 only thing using futurize to prepare
> the ground. This is really an extension of what is currently happening
> of course, but with a turbo charger. Let us insist that the SCons
> default branch is "futurize -1" with all __future__ imports in place,
> so that all Python 2.7 code is using Python 3 semantics where
> possible.
> 
> I think this is reasonable, but I don't know what effort has been made prior 
> to now.
>  

As I said, the “-1” is completely safe as it is just modernizing from python 
2.6- to 2.7.

> 
> This can happen within the current infrastructure effectively
> unchanged. Obviously all CI should be green with each changeset. I
> suspect it will not run under Python 3 in this form.
> 
> When this is done, we can add the "futurize -2" with the dependency on
> future, obtained not by vendorizing but by package management install.
> This should leave the Python 2.7 CI still green – assuming all the CI
> servers have future installed. (With Codeship and Drone this is handled
> by using a requirements.txt file in the usual pip-ish way.) Then the
> work of getting a Python 3 CI green can happen, with the Python 2.7 CI
> always green.
> 
> I'd prefer to make a solid attempt to not have a dependency of future if 
> possible.
> 

To do that you will find that you have to write a lot of support code that 
handles the version differences. future has already done that though.

> Once it is added, chances are it will never be refactored out...
>  

The big difference between future and six is that in future the code you end up 
with looks like python3 code with some imports at the top (which are mostly 
no-ops on python3). With six you find that your code is full of six calls which 
it seems to me would be harder to remove.

— 
Tim Jenness

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

Re: [Scons-dev] Python 3 strategy

[William Blevins]

Yeah we wouldn't delete the current changes.
On Jan 25, 2016 3:22 PM, "Gary Oberbrunner"  wrote:

>
> On Mon, Jan 25, 2016 at 4:39 AM, Russel Winder 
> wrote:
>
>> The alternative is to abandon the current python3-port and start again
>> from default based solely on future.
>>
>
> This doesn't seem crazy to me, although there was a LOT of hand-tweaking
> of code on the current python3 branch: utf8/locale stuff, print stmts,
> which in a fair number of cases didn't look like any automation would've
> caught them. So if you start again I suspect most of that work will have to
> be redone. I spent a couple of days on it, iirc, and I wasn't the only one.
> Maybe some of those changes could be cherry-picked over? I suggest skimming
> some of my changes on that branch (not the merges, just the by-hand stuff)
> to get a sense of what had to be done.
>
> --
> 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] Python 3 strategy

[Gary Oberbrunner]

On Mon, Jan 25, 2016 at 4:39 AM, Russel Winder  wrote:

> The alternative is to abandon the current python3-port and start again
> from default based solely on future.
>

This doesn't seem crazy to me, although there was a LOT of hand-tweaking of
code on the current python3 branch: utf8/locale stuff, print stmts, which
in a fair number of cases didn't look like any automation would've caught
them. So if you start again I suspect most of that work will have to be
redone. I spent a couple of days on it, iirc, and I wasn't the only one.
Maybe some of those changes could be cherry-picked over? I suggest skimming
some of my changes on that branch (not the merges, just the by-hand stuff)
to get a sense of what had to be done.

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

Re: [Scons-dev] CI stuff

[Bill Deegan]

Russel,

Let me contact drone.io and see if we can get a free open source account?
I know I spoke with another CI vendor and they said they'd be willing to.
Are you currently developing on a branch, or default?

-Bill

On Mon, Jan 25, 2016 at 3:51 AM, Russel Winder  wrote:

> On Mon, 2016-01-25 at 08:42 +, Russel Winder wrote:
> > Codeshio.ip shows a very sensible ignore and fail lists, in that it
> > concurs with my local builds. :-)
> >
> > Lots of work to be done. For me the real irritant is why the mkfifo
> > test fails.
> >
> > Drone.io bombs out after 15 minutes on free accounts, SCons tests
> > take
> > longer than 15 minutes.
> >
>
> The Codeship build took 15mins and 6secs, why couldn't Drone go with 16
> mins?
>
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> ___
> 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] CI, Semaphore, Shippable

[Russel Winder]

It appears that everyone in the "in the cloud" CI game other than
Codeship and Drone assume that all repositories on BitBucket are Git
ones.

I have asked Drone for special dispensation for long test times for
SCons repositories.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



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] Python 3 strategy

[William Blevins]

On Mon, Jan 25, 2016 at 9:39 AM, Russel Winder  wrote:

> I am having difficulty making a decision…
>
> The earlier Python 3 branch is founded on using six. At the time a good
> decision. Now however we have agreed that 2.7 is the base version and
> thus future rather than six is the better tool for Python 3. This
> brings into doubt the python3-port branch as a good base of operations.
>
> William has done some work changing the python3-port branch, as have I,
> all based on the massive previous work. Despite all this effort I
> wonder if we have the right base to progress further. Maybe we have and
> carry on, but now is the time to stop before much more effort goes in
> if this is not the way forward.
>
> The alternative is to abandon the current python3-port and start again
> from default based solely on future.
>
> Instead of having a separate branch, let us work solely on default,
> turning it first into a Python 2.7 only thing using futurize to prepare
> the ground. This is really an extension of what is currently happening
> of course, but with a turbo charger. Let us insist that the SCons
> default branch is "futurize -1" with all __future__ imports in place,
> so that all Python 2.7 code is using Python 3 semantics where
> possible.
>

I think this is reasonable, but I don't know what effort has been made
prior to now.


>
> This can happen within the current infrastructure effectively
> unchanged. Obviously all CI should be green with each changeset. I
> suspect it will not run under Python 3 in this form.
>
> When this is done, we can add the "futurize -2" with the dependency on
> future, obtained not by vendorizing but by package management install.
> This should leave the Python 2.7 CI still green – assuming all the CI
> servers have future installed. (With Codeship and Drone this is handled
> by using a requirements.txt file in the usual pip-ish way.) Then the
> work of getting a Python 3 CI green can happen, with the Python 2.7 CI
> always green.
>

I'd prefer to make a solid attempt to not have a dependency of future if
possible.

Once it is added, chances are it will never be refactored out...


>
> Of course even though the Python 2.7 tests are red, and the Python 3
> tests do not run, python3-port on Python 3.5 and 2.7 actually works.
> This is the opposite side of the coin, why change strategy now?
>

Does SCons appear to function in the branch? I haven't tried actually
compiling anything?

There aren't that many 2.7 tests failing. It's less than 50 on my Linux
configuration, and I have most of the tools setup. Not sure what the other
platforms look like...


>
>
> --
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> ___
> 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] Python 3 strategy

[Russel Winder]

I am having difficulty making a decision…

The earlier Python 3 branch is founded on using six. At the time a good
decision. Now however we have agreed that 2.7 is the base version and
thus future rather than six is the better tool for Python 3. This
brings into doubt the python3-port branch as a good base of operations.

William has done some work changing the python3-port branch, as have I,
all based on the massive previous work. Despite all this effort I
wonder if we have the right base to progress further. Maybe we have and
carry on, but now is the time to stop before much more effort goes in
if this is not the way forward.

The alternative is to abandon the current python3-port and start again
from default based solely on future.

Instead of having a separate branch, let us work solely on default,
turning it first into a Python 2.7 only thing using futurize to prepare
the ground. This is really an extension of what is currently happening
of course, but with a turbo charger. Let us insist that the SCons
default branch is "futurize -1" with all __future__ imports in place,
so that all Python 2.7 code is using Python 3 semantics where
possible. 

This can happen within the current infrastructure effectively
unchanged. Obviously all CI should be green with each changeset. I
suspect it will not run under Python 3 in this form.

When this is done, we can add the "futurize -2" with the dependency on
future, obtained not by vendorizing but by package management install.
This should leave the Python 2.7 CI still green – assuming all the CI
servers have future installed. (With Codeship and Drone this is handled
by using a requirements.txt file in the usual pip-ish way.) Then the
work of getting a Python 3 CI green can happen, with the Python 2.7 CI
always green.

Of course even though the Python 2.7 tests are red, and the Python 3
tests do not run, python3-port on Python 3.5 and 2.7 actually works.
This is the opposite side of the coin, why change strategy now?
 
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



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

[Scons-dev] Mercurial remote tracking

[Russel Winder]

HgView shows remote tracking branches. Pity HgView is a Qt application
rather than a GTK+ one: it looks horrible on my screen, especially
compared to gitg.

I still prefer the Git transient branch model to the Mercurial
persistent branch model.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



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] On CI

[William Blevins]

On Jan 25, 2016 6:57 AM, "Russel Winder"  wrote:
>
> Independent of any CI Bill is running with Buildbot, I think we should
> make use of any and all CI that Atlassian and others connect to
> BitBucket, in the same way TravisCI etc. connect into GitHub.
>
> Having three or four CI instances all monitoring GitHub repositories
> and running tests on every commit and every pull request provides a lot
> of very useful support.
>
> Whilst BitBucket is now clearly a Git resource, it is still providing
> Mercurial services and the pull requests and general management is
> effectively as good as GitHub. If BitBucket can do issue handling, pull
> requests, repository management, and CI (the big one), more or less as
> well as GitHub, then there seems no reason to abandon BitBucket. In
> fact exactly the opposite, if we can avoid moving from BitBucket now,
> that is a good thing.
>
> Switching from Mercurial to Git however is a completely different
> issue. In the short term there is no big deal per se (other than most
> of the core developers want to use Git not Mercurial!). However it is
> clear Atlassian are pitching BitBucket as a Git repository management
> system. In effect, as people at O'Reilly said in 2006-ish, Git has won
> the DVCS war. Mercurial is though a contender left in the main game,
> all others are now just history with niche markets. (Sad, I liked
> Bazaar.)
>
> I am going to start using the issue tracker on my Python 3 SCons port,
> that William is now also tinkering in, to see how it feels. Also I will
> try out as many CI systems as I can connect in so as to run Python 2.7
> and Python 3.4 tests for each commit and pull request. I am expecting
> some glitches compared to GitHub, but I am confident Atlassian will be
> fixing things.
>
> I note immediately that the BitBucket issues system is not JIRA. I am
> assuming it is a stripped down, loss leader version to sell JIRA
> instances.
>

We may be able to get free Jira by applying open source. Atlassian
otherwise will not give out non-free Jira to the plebeians.
> --
> Russel.
>
=
> Dr Russel Winder  t: +44 20 7585 2200   voip:
sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>
>
> ___
> 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] CI stuff

[Russel Winder]

On Mon, 2016-01-25 at 08:42 +, Russel Winder wrote:
> Codeshio.ip shows a very sensible ignore and fail lists, in that it
> concurs with my local builds. :-)
> 
> Lots of work to be done. For me the real irritant is why the mkfifo
> test fails.
> 
> Drone.io bombs out after 15 minutes on free accounts, SCons tests
> take
> longer than 15 minutes.
> 

The Codeship build took 15mins and 6secs, why couldn't Drone go with 16
mins?

Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



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

[Scons-dev] CI stuff

[Russel Winder]

Codeshio.ip shows a very sensible ignore and fail lists, in that it
concurs with my local builds. :-)

Lots of work to be done. For me the real irritant is why the mkfifo
test fails.

Drone.io bombs out after 15 minutes on free accounts, SCons tests take
longer than 15 minutes.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



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

[Scons-dev] On the state of CI

[Russel Winder]

I have a Drone.io account and have set up a Python 2.7 test CI on it
for my SCons__Python3 repository and the python3-port branch. It's very
red.

 https://drone.io/bitbucket.org/russel/scons__python3

I have created Shippable and Semaphoe accounts, but there is no CI as
yet because they cannot see public repositories only private ones.

I have a Codehsip account and added a build:

https://codeship.com/projects/129569

TravisCI is GitHub only, so no activity on that.

TeamCity is not SaaS, you need a server. No action.

Jenkins is not not SaaS, you need a server. No action.


Bamboo – experience using this with Groovy, Gant, and GPars was mixed,
but I cannot find a free Bamboo service that connects with BitBucket.
This is surprising. 


-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip:sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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