On Sunday, 4 January 2015 at 17:18:22 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 4 January 2015 at 14:50, Joakim via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
Annoyance also extends out to maintainers too (I could write a
book
about Where DMD went wrong? Some more of DMD's greatest
mistakes, and
Just who is this DMD compiler anyway?)
I'd be interested in reading that, you should write it up
somewhere.
Tell that to the most widely used open-source projects these
days, ie hybrid
projects like Android, iOS/OS X, llvm/clang, Chrome, etc.
There are
advantages to both the cathedral and the bazaar model, which
is why it's
best to mate the two, as has been done by the listed highly
successful
software.
At least three of those projects I would see as anything but
bazaar. :)
I'd say three are hybrids to varying degrees and iOS/OSX is
largely cathedral nowadays, despite its bazaar BSD antecedents.
I was referring to patches from closed merging upstream.
One example would be, oh, DIP-25 being implemented in the closed
frontend - let's say Walter implemented it, then someone from
the
community implements DIP-25 in a differing way and raises a PR a
couple months later. Should the PR be accepted? If it is
should the
closed implementation be dropped? Because of the closed nature
there's no way to compare which one is more technically sound
than the
other.
There is no reason for the open source project to defer a PR
because of closed patches that aren't available yet. Once the
closed patches are opened, the two implementations can be merged
for their best aspects.
This is what happened with the AArch64 backend for llvm recently:
devs were working on an OSS backend and Apple developed their own
closed one quicker and shipped it for the recent port of iOS to
64-bit. Later, Apple opened up their closed backend, and the two
were merged. I believe they ended up going with the closed one
and merging back pieces of the existing OSS one that they wanted.
There's also a question of timing too. Obviously such an
undertaking
shouldn't happen until the frontend switches to D, nor when
there are
still plenty of visitor re-writes being done in the frontend.
I doubt either would preclude doing it now, as the closed patches
would be continually rebased on the OSS frontend.
Was Walter selling a paid compiler with the then-closed dmd
backend? If
not, the comparison is not valid. The idea here is for paying
customers to
fund closed patches for a limited time, and speed up D
bug-fixing and
development much more. If Walter was not getting paid for his
closed
backend but only keeping it closed because of licensing
issues, the
situations are completely different.
For me, the comparison is between these key timelines:
- No source code
- D1 Frontend released as Artistic/GPL
- Backend released under restricted license
- Moving to Github
- Creating a 'core' team
- Everyone (even Walter!) switching over to the PR patch
submission/review system
- Re-license Frontend as Boost
Each point over a 14 year history has been a step in the
direction of
being 'open' and each brought a boost in development. The
number of
changes between each release compared to back in 2.020 days is
a clear
sign of this - as well as the three digit open PRs.
Your point seems to be that D moving from a one-man, closed
project by Walter to an OSS project with several contributors
greatly sped up its development. Nobody is disputing that.
The question is how to attain the next level of growth, speeding
it up a lot more, and I think this hybrid approach will do that.
On Sunday, 4 January 2015 at 16:54:17 UTC, Martin Nowak wrote:
On 01/04/2015 09:31 AM, Joakim wrote:
I don't think anyone has an interest of closed patches.
Building a point release with the bug fixed might be of more
interest.
That's merely a matter of packaging, there are several ways it
can be done with the closed patches. Of course, initially only
providing closed patches against the stable OSS point releases
would be an easy way to start.
