On 10 August 2015 at 18:30, Martin Nowak via dmd-internals <dmd-internals@puremagic.com> wrote:
With the 2.068.0 out the door let's look ahead and plan the next 2 weeks.

Small retro:

Lot's of momentum in the final release phase just look at our done board
(https://trello.com/b/XoFjxiqG/active, cards will get archived in 2
days). Thanks to the many people helping out.

Let's keep it that way for the next release, though we should spare the
initial inertia (the release took more than 4 weeks).

As a reminder 2.068.1 is due in 1 month, 2.069.0 in 2 month.
I'm aiming for a 1 week beta period for point releases and 2 weeks for
full releases, i.e. 3 weeks until 2.068.1-b1 and 6 weeks until 2.069.0-b1.

Planning:

There are a few leftover things from the release phase that we should
handle before jumping on ddmd work.

- Dropping -property waits for an offical OK from Walter
  https://trello.com/c/1dQh4gxm/35-drop-property

- Debug druntime tests wait for someone to look at FBSD
  shared library guts
  https://trello.com/c/zmsotPH2/20-fix-debug-druntime-tests-for-fbsd

- There is some pending work on VS2015 support
  https://trello.com/c/5OWcNIGy/33-vs2015-support

- m32coff targets are here and simply need to be wired
  with the release scripts
  https://trello.com/c/al6RlkJP/44-mscoff32-libs-for-release

- We hackfixed a mangling issue for mixins and lambdas
  and need to come up with a proper solution.

https://trello.com/c/YuW4JycJ/45-mangling-of-mixins-and-lambdas-can-change-w-unittest-or-other-versions

- I noticed a few missing things while documenting the rangified functions.
  https://trello.com/c/vC7GfbPA/46-follow-up-on-rangified-functions

- I want to finish my WIP smart refs which didn't make it for 2.068.0
  https://trello.com/c/pTlDuyBD/16-finish-smartref-implementation

- The newly added compiler internal helper functions should get their
own module or so instead of being appended to object.d

https://trello.com/c/Vf4Gasoa/47-follow-up-on-compiler-internal-helper-module-and-arraydtor-error-messages


DDMD:

Regarding the ddmd switch I'd suggest to first make a spec story to
understand and break down what needs to be done. We should closely
coordinate this with people from the GDC and LDC team.

https://trello.com/c/4NtxWDtK/48-ddmd-bootstraping-and-backwards-compatibility-guarantees

Discussing this on dmd-internals seems like a good idea to me.

Then we can schedule whatever tasks fall out of the discussion for this
and the next sprint.


- Do we need to keep ddmd working with 2.068?

For the time being, yes, and for as long as possible.

I'd like to see continual bug fix releases incase anything slipped into 2.067 or 2.068 that broke GDC or LDC's any part of their interface, codegen or strictly-typed backend.  (See for instance, PRs 4062, 4075, 4077, 4212, and probably many more just to get 2.066 working).


- When will gdc and ldc catch up and switch to a self-hosted frontend.

No set time on my side.  Currently I'm doing what is effectively a 70-80% rewrite of all codegen.  Eg: This is for the complete removal of the IRState definition from our glue.

https://github.com/D-Programming-GDC/GDC/commit/f7ad1ef43021e95eb4af387fa1cf300f9da856b9

I've written up a wiki (both myself and Johannes are crossing things off as we complete them):

http://wiki.dlang.org/GDC/CurrentReleaseTasks


- Any bootstrap strategies for cross compiling?

Initially, use 2.068 as baseline, then bootstrap with the later versions (written in D).  This could be integrated into the GCC build without too much hassle, as they themselves have a three-stage build+bootstrap process.

I'm admittedly worried that this will block any work I'm doing with upstream GCC.  In my most ideal case, I'd want 2.068 merged into the GCC ecosystem, then have it trickled down into all major vendors in whatever major release we end up being shipped in before switching.  This gives distributors the best opportunity to manage building the self-hosted sources without running into an impossible Catch-22 situation.

Debian/Ubuntu are currently in the best position as the maintainer has kindly integrated GDC into the GCC binaries (albeit with favours):

https://packages.debian.org/sid/gdc-5

I would like to see libphobos (or at least libdruntime) being made available for more targets though.

Current list is: [amd64, armel, armhf, i386, x32]


- How to test compatibility?

Compatibility with what?  ARM? SPARC? PPC?  Communicating across C++ <-> D?


Regards
Iain.