10th Birthday for GDC

[Iain Buclaw]

On 31 January 2014 01:39, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> On 1/30/14 4:13 AM, Iain Buclaw wrote:
>>
>> Hi all,
>>
>> On March 22, 2014, GDC will turn 10! \o/
>>
>> This is a great landmark achievement in brevity for GDC, but we still
>> haven't achieved in my personal opinion any levity of worthy note.  So
>> much to the point I'm beginning to give doubt myself as to how long
>> things can continue with a bus-factor of me.
>
>
> Congratulations!
>
>
>> Lets talk history.
>>
>> In late 2010, Digital Mars raised awareness with the FSF to start the
>> process of merging GDC into GCC.  Nothing then happened until a year
>> later when the copyright assignment/disclaimers had been completed by
>> most parties.
>>
>> More silenced followed for a further year until the first set of patches
>> were ready for submission, and over the year that followed resolving
>> implementation issues, most were spent waiting for GCC development to
>> re-open for feature pulls.  Now a further year has gone by with that
>> merge window open and shut and we are once again two releases away from
>> seeing any possible inclusion.
>
>
> Sucks to be an evangelist, eh? :o) The thing is, most of the people in this
> forum are blissfully unaware of GNU's process, milestones, and deadlines. I
> know it's unpleasant to do so, but one thing to do would be to
> overcommunicate. There's a lot to be said about reminding people, time and
> again, about an impending deadline and what they can do to help. Messages in
> with titles like the samples below would make a world of difference:
>
> [GDC] Four pulls up for review, aiming at GNU acceptance in three months
> [GDC] Help needed: front-end pull, blocks GNU acceptance in two months
> [GDC] URGENT: three weeks to GNU deadline, please review!
> etc.
>
> This kind of work is as important as the technical work you're doing
> (actually more important right now). It is true that more people would see
> others get the work done and they just download the GNU suite with GDC in
> it. But there's plenty of evidence there are many collaborators who are
> eager to help and simply don't have any information on what exactly which
> rocks to lift and where to take them. You need to be the guy coordinating
> that, and once per decade is not enough :o).
>
>



>> On top of this, to this day I am yet to hear that the assignment papers
>> have been completed by the original author, which would be a major
>> blocker in itself.
>
>
> Who's that guy and what code did he write? If no response, let's redo his
> work. We should not be afraid of it.
>

David Friedman, I'm in direct contact with him and give both him and
Donald (the FSF assignments clerk) a nudge over the issue once every
couple of months.  Whilst David has no problem, he is in the
unfortunate position of having his IP owned by a company.  And at last
check, they were still dealing with clauses in the assignment.

As for the codebase, I can say that around 60% has been potentially
re-written since I picked it up in 2008/2009.


>
>> Alarm bells should be ringing, but at times there seems to be an
>> indifference from the core community on the matter, as if letting a
>> valued D compiler coming up to 10 years of age go awry because of a lack
>> of TLC is O.K.
>
>
> (TLC = tender loving care?)
>
> An increasing number of people depend on GDC for getting work done.
> Including a couple of projects here at Facebook. Yet the simple reality is
> that even if I summoned TODAY one of our engineers with "get on helping gdc
> full time", that engineer would have absolutely no idea where to start.
>

The same could be said with DMD.  I'd never expect someone to pick up
a 20k codebase in a week, but one can do it in small steps.  In my
opinion, the best way to get stuck into GDC is to do a couple of
frontend merges (2.064 -> 2.065 -> future).


>> Before this comes to sound like a death note, please be rest assured
>> that my continued contribution shall remain, but some form of serious
>> support really is needed to speed up process and development if we are
>> even going to achieve any target we have set our sights on.
>>
>> Lets discuss what we can positively do about the situation and start
>> working together to a pillar goal in D's continued success.  Unless the
>> more proactive thing to do would just be to walk in-front of that
>> morning or afternoon bus instead of board it. :)
>
>
> Absolutely! And your note is a great breaker of the thundering silence
> around working together to get gdc where it belongs.
>
> That being a large endeavor, there's one time-honored way to address it:
> divide it into smaller steps. So here are a few thoughts:
>
> * Use this forum for EVERYTHING related to gdc, EXCLUSIVELY. Prefix
> everything with [gdc] so nobody will complain about being spammed.
>
> * Keep people posted about ALL upcoming milestones and deadlines of the
> relevant gnu process.
>
> * Find the SMALLEST indivisible step that would help push gdc toward
> integration, file it under bugzilla, and tag it with "gdc". Repeat this many
> times.
>
> * Ask the community for help NOT on a large matter. Ask for help for EACH
> SMALL STEP that a competent person can get on to. I bet many in this
> community read your anniversary message and were like, "wow, tricky..." and
> back to browsing. I take it
> https://github.com/D-Programming-Language/dmd/pull/2200 and
> https://github.com/D-Programming-Language/dmd/pull/2194 are two important
> ones, is that correct?
>

Differences between gdc and dmd in the frontend implement are important.

GCC has a strict backend and will ICE at any opportunity it can find.
As GDC has been well tailored to this over the years to produce
correct code for GCC.  Things like this in GCC can flag up any big
problems in the frontend quite easily.  Regardless of whether or not
DMD compiles it without a hitch.

Having arbitrary changes to the frontend means that not just anyone
can pick up the latest version of D and slot it in.  Internal
knowledge of what changes are present in that patch, and why in my
head after months of study and testing.  It makes merges more
difficult, setting aside changes in the frontend have a hidden
knock-on effect in the glue.

> I'll do my best on my side to help with very concrete bits, i.e. put
> bounties on important issues or have legal contact people for signatures.
> But I need to know!
>

If you can get me in touch with your guy, I could do with a hand in
having a third party look over my own code reviews, which doesn't
require any previous knowledge of gdc.

http://gcc.gnu.org/codingconventions.html