[OT] LLVM Community Code of Conduct

[Johannes Pfau via Digitalmars-d]

Am Tue, 20 Oct 2015 22:02:17 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d at puremagic.com>:

> On 20 October 2015 at 20:44, Vladimir Panteleev via Digitalmars-d <
> digitalmars-d at puremagic.com> wrote:
> 
> > On Monday, 19 October 2015 at 21:24:00 UTC, Iain Buclaw wrote:
> >  
> >> In order:
> >> You are responsible, the library maintainers (I chip in a bit on
> >> the side when I have the hardware / virtual environment).
> >> You are responsible, the authors and reviewers of the testsuite and
> >> unittests.
> >>  
> >
> > Who is this "You", specifically?
> >
> > If I run into a bug with GDC on a specific platform/architecture,
> > who am I supposed to talk to? With DMD/Phobos bugs I can at least
> > use "git blame".
> >
> > Also, are you saying that it is every Phobos/Druntime contributor's
> > responsibility to make sure that their changes are GDC-compatible?
> > Other than the Travis auto-tester which seems to be failing half
> > the time, we don't have any CI or any tests at all for GDC!
> >
> >  
> 
> What can I say?  We have a lot of faith in our porters. :-)
> 
> 
> You can talk to me if you run into any problems, because I'm
> certainly more *aware* of porting and portability than most other
> druntime and compiler maintainers.  However you submit to upstream.
> 

To further explain this: Our GDC policy is to not accept changes into
druntime or phobos which have not been constributed in druntime /
phobos upstream (D-Programming-Language) first.
Having too many local changes in the GDC version makes merging new
versions much more complicated (and also means the GDC team has to
maintain that code), so we obviously like to avoid that.

There are some compiler specific things in druntime: Basically
everything in gcc.* Changes to these modules will need to go to GDC
repositories directly. AFAIR we also have not committed GCC inline ASM
to druntime upstream as it's not useful for DMD.

However, most changes required when porting are definitions to
C-interfacing headers, maybe some minimal GC changes and Fiber support
(now in threadasm.S) and all these changes need to go to upstream
druntime/phobos.

Another problem when porting is the testsuite. It actually contains
quite some inline ASM. It's usually very simple inline ASM so it's easy
to port but the ASM code is scattered over quite some files. I think we
also didn't upstream these changes.

It might make sense to reconsider upstreaming our inline ASM code. I
think the main reason we didn't do that yet was that the druntime
developers think of druntime as a compiler specific library anyway. And
then there's no use in having GDC specific ASM in a DMD specific
druntime.