On Tuesday, 25 February 2014 at 12:48:09 UTC, Jacob Carlborg wrote:
> On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu wrote:
>> This has been pointed out in the reddit thread - it's an automated platform that should make our betas much easier to work with. Thoughts?
>>
>> Andrei
>
> I like the idea, but I think the first step would be to make sure D is officially support on Travis CI. Then start thinking about this.
>
> --
> /Jacob Carlborg

I strongly agree. Travis is already well established in the open source world, and integrates well with github, which is where most of D project are hosted AFAIK. Putting our effort to make Travis works with D smoothly will bring much more benefit, both in short and long term than creating yet another D-specific tool.
Note: Vibe.d is already using Travis.

On Tuesday, 25 February 2014 at 12:48:09 UTC, Jacob Carlborg wrote:
> On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu wrote:
>> This has been pointed out in the reddit thread - it's an automated platform that should make our betas much easier to work with. Thoughts?
>>
>> Andrei
>
> I like the idea, but I think the first step would be to make sure D is officially support on Travis CI. Then start thinking about this.
>
> --
> /Jacob Carlborg

It would be nice if it had an API available that didn't force you to use Travis.

For my own CI purposes, I use Bamboo with a D plugin I made and find it works quite nicely. In theory it could be quite simple for that to add integration with this system.

On Tue, 25 Feb 2014 17:27:33 -0800, Kapps <opantm2+spam@gmail.com> wrote:

> On Tuesday, 25 February 2014 at 12:48:09 UTC, Jacob Carlborg wrote:
>> On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu wrote:
>>> This has been pointed out in the reddit thread - it's an automated platform that should make our betas much easier to work with. Thoughts?
>>>
>>> Andrei
>>
>> I like the idea, but I think the first step would be to make sure D is officially support on Travis CI. Then start thinking about this.
>>
>> --
>> /Jacob Carlborg
>
> It would be nice if it had an API available that didn't force you to use Travis.
>
> For my own CI purposes, I use Bamboo with a D plugin I made and find it works quite nicely. In theory it could be quite simple for that to add integration with this system.

We use Bamboo at work and I like it quite a lot. Like all Atlassian products it's free for Open-Source projects and it comes with source code. It also has a very expansive REST API.

But I'm not opposed to any CI so long as it does what we need it to do. Mostly we just need CI. I still think that the Auto-Tester would be the path of least resistance on this...

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 2/25/14, 8:30 PM, Adam Wilson wrote:
> On Tue, 25 Feb 2014 17:27:33 -0800, Kapps <opantm2+spam@gmail.com> wrote:
>
> We use Bamboo at work and I like it quite a lot. Like all Atlassian
> products it's free for Open-Source projects and it comes with source
> code. It also has a very expansive REST API.
>
> But I'm not opposed to any CI so long as it does what we need it to do.
> Mostly we just need CI. I still think that the Auto-Tester would be the
> path of least resistance on this...

The 'build' part of the auto-tester is the easiest part.  The majority of the logic is in what to build when and the user interface on top of that state.  None of that exists for this use case.  It's not hard logic, but it would need to be built.

This use case can likely also ignore the multi-platform part and stick to just building on one which simplifies the job significantly.  And it can also likely all be done on one box since it's likely that it can all be done in a relatively short period of time.

All that, in my mind, suggests that while it could be integrated into the auto-tester, it gains little in doing so and puts more work on my plate and more load on already loaded systems.  I think having a new volunteer involved would be more long term beneficial.

Later,
Brad

On Tue, 25 Feb 2014 20:50:49 -0800, Brad Roberts <braddr@puremagic.com> wrote:

> On 2/25/14, 8:30 PM, Adam Wilson wrote:
>> On Tue, 25 Feb 2014 17:27:33 -0800, Kapps <opantm2+spam@gmail.com> wrote:
>>
>> We use Bamboo at work and I like it quite a lot. Like all Atlassian
>> products it's free for Open-Source projects and it comes with source
>> code. It also has a very expansive REST API.
>>
>> But I'm not opposed to any CI so long as it does what we need it to do.
>> Mostly we just need CI. I still think that the Auto-Tester would be the
>> path of least resistance on this...
>
> The 'build' part of the auto-tester is the easiest part.  The majority of the logic is in what to build when and the user interface on top of that state.  None of that exists for this use case.  It's not hard logic, but it would need to be built.
>
> This use case can likely also ignore the multi-platform part and stick to just building on one which simplifies the job significantly.  And it can also likely all be done on one box since it's likely that it can all be done in a relatively short period of time.
>
> All that, in my mind, suggests that while it could be integrated into the auto-tester, it gains little in doing so and puts more work on my plate and more load on already loaded systems.  I think having a new volunteer involved would be more long term beneficial.
>
> Later,
> Brad

Well, in my CI experience at work you want to run CI on every platform your trying to support as each is a different environment, and the AT has access to all of them. As for system load, you wouldn't do this in the pull tester. I'd argue that use this would increase load somewhat, but not significantly...

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 2014-02-26 05:50, Brad Roberts wrote:

> The 'build' part of the auto-tester is the easiest part.  The majority
> of the logic is in what to build when and the user interface on top of
> that state.  None of that exists for this use case.  It's not hard
> logic, but it would need to be built.
>
> This use case can likely also ignore the multi-platform part and stick
> to just building on one which simplifies the job significantly.  And it
> can also likely all be done on one box since it's likely that it can all
> be done in a relatively short period of time.
>
> All that, in my mind, suggests that while it could be integrated into
> the auto-tester, it gains little in doing so and puts more work on my
> plate and more load on already loaded systems.  I think having a new
> volunteer involved would be more long term beneficial.

How much worked would it be to rewrite the auto tester to not use the proprietary systems it currently does? I'm thinking this would make it easier for others to help.

-- 
/Jacob Carlborg

On 2014-02-26 05:50, Brad Roberts wrote:
> Later,
> Brad

Hi, It's kinda hard to reach you by email, I've sent 3 of them :) Would you like to accept ARM board for auto tester? Please contact me on NG email if you wish.

On 2014-02-26 05:50, Brad Roberts wrote:
> Later,
> Brad

Now I've received your email but it seems I can't reply :)

Instead, I'm receiving mail delivery error:

 The mail system

<braddr@puremagic.com>: host mail2.puremagic.com[99.179.5.161] said: 451
4.7.1
    Please try again later (TEMPFAIL) (in reply to RCPT TO command)

Well, it sounds like one of two issues:

1) you're mail client is sending directly to the mx hosts for puremagic.com mails (ie, mail1 or mail2) and never retrying to send. Neither is a good idea.

or

2) your mail transport agent is never retrying.

I suspect the former more than the latter, though that'd be highly unusual for a mail client to do.

Either way, the 'error' message there is fully descriptive.  You need to re-try the send later.  This is standard greylisting behavior which both mail servers for puremagic.com use.

On 2/27/14, 1:47 AM, Piotr Szturmaj wrote:
> On 2014-02-26 05:50, Brad Roberts wrote:
>> Later,
>> Brad
>
> Now I've received your email but it seems I can't reply :)
>
> Instead, I'm receiving mail delivery error:
>
>   The mail system
>
> <braddr@puremagic.com>: host mail2.puremagic.com[99.179.5.161] said: 451
> 4.7.1
>      Please try again later (TEMPFAIL) (in reply to RCPT TO command)