On 07/09/2015 09:56 PM, Iain Buclaw wrote:
> If I imposed this more strictly, we would instead have:
> 
> 4.8.4+2.064.2
> 4.9.2+2.065.0
> 5.1.0+2.066.1
> 6.0.0+2.067-dev
> 
> Yes, DMD releases take so long, they are pretty much in sync with GCC. (Although, still one release behind DMD by the time I manage to complete the merge ;-)

We're trying to adopt a 2 month release cycle with a point release in between.

On 07/09/2015 10:37 PM, Iain Buclaw wrote:
> I actually had a good rant about this last month, because I can no longer wait for the broken auto-tester to start working on all platforms, but all alternates are useless offers for medium to large open source projects.
> 
> So it was quite a relief to find out that Semaphore offers:
> - 4GB "soft" limit, doesn't actually kill your build/tests if you sometimes
> exceed.
> - 60 minute limit "per command", so you could have 24 commands that each
> take 59 minutes and things will continue to build.
> 
> Everything I've thrown at it, it has consumed with delight and succeeded. This makes me a happy user.

Depends on how long they can sustain offering high performance root
servers for free. Doesn't sound like a feasible business model.
But indeed there seems to be a market niche for a service that offers
few but resource intensive builds per month, as opposed to many less
intensive test cycles.

BTW, I have a nice card in the backlog, writing a heroku buildpack for D.
https://trello.com/c/XsuNi8bt/18-heroku-buildpack-for-d
Heroku is a slightly expensive, but heavly used PaaS.
They offer a free tier (https://www.heroku.com/pricing) that has plenty
of resources to deploy small vibe.d apps.

On 07/09/2015 09:01 PM, Jacob Carlborg wrote:
> 
>> On 9 jul 2015, at 15:14, Martin Nowak via dmd-internals <dmd-internals@puremagic.com> wrote:
>>
>> We cannot succeed by dumping code into the master branch. It's important that we develop with the next release in mind.
> 
> If you’re concerned about code added to the master branch that should not be part of the release, shouldn't there be a release branch then?
> 

We have a release branch, it's called stable. https://github.com/D-Programming-Language/dmd/tree/stable

Sigh, guess I'll have to repeat that for a while. http://wiki.dlang.org/DIP75

On 7/10/15 9:50 AM, Martin Nowak via dmd-internals wrote:
> On 07/09/2015 09:01 PM, Jacob Carlborg wrote:
>>
>>> On 9 jul 2015, at 15:14, Martin Nowak via dmd-internals <dmd-internals@puremagic.com> wrote:
>>>
>>> We cannot succeed by dumping code into the master branch.
>>> It's important that we develop with the next release in mind.
>>
>> If you’re concerned about code added to the master branch that should not be part of the release, shouldn't there be a release branch then?
>>
>
> We have a release branch, it's called stable.
> https://github.com/D-Programming-Language/dmd/tree/stable
>
> Sigh, guess I'll have to repeat that for a while.
> http://wiki.dlang.org/DIP75

So whenever we start a new release, we branch master into stable. Why, then, is it unadvisable to just continue business as usual in master? Sorry for the silly question, just learning the ropes. -- Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 10 July 2015 at 00:46, Martin Nowak via dmd-internals < dmd-internals@puremagic.com> wrote:

> On 07/09/2015 09:56 PM, Iain Buclaw wrote:
> > If I imposed this more strictly, we would instead have:
> >
> > 4.8.4+2.064.2
> > 4.9.2+2.065.0
> > 5.1.0+2.066.1
> > 6.0.0+2.067-dev
> >
> > Yes, DMD releases take so long, they are pretty much in sync with GCC. (Although, still one release behind DMD by the time I manage to complete the merge ;-)
>
> We're trying to adopt a 2 month release cycle with a point release in between.
>

Please chime into D.gnu.  Myself and Johannes are talking re-structuring the FTP downloads now.

Regards
Iain

On 07/10/2015 03:57 PM, Andrei Alexandrescu wrote:
> So whenever we start a new release, we branch master into stable. Why, then, is it unadvisable to just continue business as usual in master? Sorry for the silly question, just learning the ropes. -- Andrei

It's not unadvisable, except for competing with dev resources. The problem I was talking about is the buisness as usual part.

Right now features often land as multiple PRs against master, or some
feature gets merged under the condition of a follow-up PR.
Sometimes those PRs spread over more than the 2 month release period.

We then end up with lots of incomplete features when merging master into stable. It's not feasible for me or anyone to track every development activity.

The cleanest solution would be to complete features in a branch to a releasable state and only then merge them, i.e. stop developing on master.

On reason for splitting up features into multiple PRs is to make them easier to review. This could be done by breaking down stories/features into smaller parts, and doing a review on the feature branch when a milestone has been completed.

On 7/10/15 10:38 AM, Martin Nowak via dmd-internals wrote:
> The cleanest solution would be to complete features in a branch to a
> releasable state and only then merge them, i.e. stop developing on master.

Got it. Yah, that should be the case for complex features. BTW this brings up the matter of single repo development... we use that at Facebook and are happy with it. -- Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Friday, July 10, 2015 11:48:21 Andrei Alexandrescu via dmd-internals wrote:
> On 7/10/15 10:38 AM, Martin Nowak via dmd-internals wrote:
> > The cleanest solution would be to complete features in a branch to a releasable state and only then merge them, i.e. stop developing on master.
>
> Got it. Yah, that should be the case for complex features.

Yeah, it makes a lot of sense for more complex stuff - particularly in the compiler - but I wouldn't think that it would make sense for most Phobos PRs.

- Jonathan M Davis

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On Jul 10, 2015, at 11:48 AM, Andrei Alexandrescu via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> On 7/10/15 10:38 AM, Martin Nowak via dmd-internals wrote:
>> The cleanest solution would be to complete features in a branch to a releasable state and only then merge them, i.e. stop developing on master.

How does that work with the auto-tester?

> Got it. Yah, that should be the case for complex features. BTW this brings up the matter of single repo development... we use that at Facebook and are happy with it. -- Andrei

At least some people aren’t permitted to pull on all repositories. How does this work with a single repository?

-Steve
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 7/10/15 2:24 PM, Steven Schveighoffer via dmd-internals wrote:
> At least some people aren’t permitted to pull on all repositories.
> How does this work with a single repository?

I don't think we need much per-repository rights, so that in particular shouldn't be much of the problem. Changing from the current setup to the other would be the main pain. -- Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals