3 ms·

The code will be submitted to Clang.

by jpgvm 11y ago

cjbprime 11y ago
Announcing that they'll throw a patchbomb at Clang at some indeterminate point in the future seems to satisfy neither the "you can get source now" nor the "this is developed in a participatory way" definitions of Open Source.
- DannyBee 11y ago
  Except, we didn't. Instead, what's happened is a discussion was started on the clang and llvm mailing lists about the best way to upstream this stuff, and as those discussions have reached consensus, patches have started flowing. See, for, example, the streamexecutor thread, etc. Also, outside of that, they've been upstreaming the non-controversial smaller stuff that is part of this for many months now. (Seriously, i think of all the companies you are going to complain about, you may want to look at google's interactions with clang and llvm, where we are actually one of the only folks who work completely upstream at all times, before throwing stones)
  - cjbprime 11y ago
    You're right, I'm not familiar with the culture of who best contributes to clang and llvm. But I know some things about what words mean, and publishing a paper describing an open source project in March and not having any code available for download in April is just kind of weird, no? It's good to talk about working out the precise mechanics of upstreaming code. But in an open source project, you'd expect to publish your fork so that other people can play an informed part in that conversation.
    - dgacmu 11y ago
      As a meta-note, your comments are coming across in a very hostile way, in case you didn't intend them that way. In an open source project, the best expectation is to play by the rules of the existing project and try to integrate your changes in the way that works well with it. There's no One True Open Source way - there are a lot of projects, each with their own cultures. What Google's done is take an internally developed thingy and transition it to LLVM. That's a pretty non-trivial effort for any company. I don't see why having it be open source has any requirement for a dump of the internal version. Earlier commenters noted already that a large fraction of the code is already present in LLVM and has been streaming in for some time now, so -- why the hostility? Collectively, I don't think "our" (the wider community) goal is necessarily to have a bunch of junk forks out there that can't be compiled or used. Working, thoughtfully contributed code is much more likely to be widely used and have a big impact, and that's a standard we should be happy if companies meet. LLVM isn't a quick hack project - it's a foundational bit of tech that millions of people depend on directly or indirectly, and that millions of people benefit from improvements to.
    - DannyBee 11y ago
      "But I know some things about what words mean, and publishing a paper describing an open source project in March and not having any code available for download in April is just kind of weird, no? " This is a lot of assumptions. For starters, it's all pretty much part of llvm 3.9 already. "It's good to talk about working out the precise mechanics of upstreaming code. But in an open source project, you'd expect to publish your fork so that other people can play an informed part in that conversation. " Actually, no, you wouldn't, at least not in these communities. In fact, in most of the projects i've been in, that's the last thing i'd want or the community would want, because it encourages people to play with these weird hybrid versions, when that's not what anyone really wants. Instead, we'd want people to come to us with design ideas, and use cases, not a fait accompli already written that they expect us to do something with. I'm not sure what projects you are part of that work the opposite way, where it's "fork everything and whatever happens happens", but it's not the majority of projects i've belonged to nor have i personally found it to be a very valuable mechanism. It makes people attached to their current implementations. When it comes to things like this, a lot of them are written the way they are not because it's a good design, but because they needed to get stuff done. Thus, discussing the use case, and design, and providing example code if people want it to play with, great. Dumping forks on the world, not a particularly useful thing in most cases except for boosting egos, IMHO (there are times it is useful,for sure, but those are mostly rare cases IMHO). Look at the history of GCC and LLVM forks. Of those who published forks and started discussion about merging those forks as-is, the number of successful merges is near zero. Of those who said 'hey, we did some cool stuff, here's our use cases and our initial thoughts on design. We have stuff that follows this design we can show but are otherwise happy to figure out the right design and build that", the number of successful merges is near 100%. So that's what was done.
maaku 11y ago
So where's the pull request?

The code will be submitted to Clang.

by jpgvm 11y ago

The code will be submitted to Clang.

Announcing that they'll throw a patchbomb at Clang at some indeterminate point in the future seems to satisfy neither the "you can get source now" nor the "this is developed in a participatory way" definitions of Open Source.

DannyBee 11y ago
Except, we didn't. Instead, what's happened is a discussion was started on the clang and llvm mailing lists about the best way to upstream this stuff, and as those discussions have reached consensus, patches have started flowing. See, for, example, the streamexecutor thread, etc. Also, outside of that, they've been upstreaming the non-controversial smaller stuff that is part of this for many months now. (Seriously, i think of all the companies you are going to complain about, you may want to look at google's interactions with clang and llvm, where we are actually one of the only folks who work completely upstream at all times, before throwing stones)
- cjbprime 11y ago
  You're right, I'm not familiar with the culture of who best contributes to clang and llvm. But I know some things about what words mean, and publishing a paper describing an open source project in March and not having any code available for download in April is just kind of weird, no? It's good to talk about working out the precise mechanics of upstreaming code. But in an open source project, you'd expect to publish your fork so that other people can play an informed part in that conversation.
  - dgacmu 11y ago
    As a meta-note, your comments are coming across in a very hostile way, in case you didn't intend them that way. In an open source project, the best expectation is to play by the rules of the existing project and try to integrate your changes in the way that works well with it. There's no One True Open Source way - there are a lot of projects, each with their own cultures. What Google's done is take an internally developed thingy and transition it to LLVM. That's a pretty non-trivial effort for any company. I don't see why having it be open source has any requirement for a dump of the internal version. Earlier commenters noted already that a large fraction of the code is already present in LLVM and has been streaming in for some time now, so -- why the hostility? Collectively, I don't think "our" (the wider community) goal is necessarily to have a bunch of junk forks out there that can't be compiled or used. Working, thoughtfully contributed code is much more likely to be widely used and have a big impact, and that's a standard we should be happy if companies meet. LLVM isn't a quick hack project - it's a foundational bit of tech that millions of people depend on directly or indirectly, and that millions of people benefit from improvements to.
  - DannyBee 11y ago
    "But I know some things about what words mean, and publishing a paper describing an open source project in March and not having any code available for download in April is just kind of weird, no? " This is a lot of assumptions. For starters, it's all pretty much part of llvm 3.9 already. "It's good to talk about working out the precise mechanics of upstreaming code. But in an open source project, you'd expect to publish your fork so that other people can play an informed part in that conversation. " Actually, no, you wouldn't, at least not in these communities. In fact, in most of the projects i've been in, that's the last thing i'd want or the community would want, because it encourages people to play with these weird hybrid versions, when that's not what anyone really wants. Instead, we'd want people to come to us with design ideas, and use cases, not a fait accompli already written that they expect us to do something with. I'm not sure what projects you are part of that work the opposite way, where it's "fork everything and whatever happens happens", but it's not the majority of projects i've belonged to nor have i personally found it to be a very valuable mechanism. It makes people attached to their current implementations. When it comes to things like this, a lot of them are written the way they are not because it's a good design, but because they needed to get stuff done. Thus, discussing the use case, and design, and providing example code if people want it to play with, great. Dumping forks on the world, not a particularly useful thing in most cases except for boosting egos, IMHO (there are times it is useful,for sure, but those are mostly rare cases IMHO). Look at the history of GCC and LLVM forks. Of those who published forks and started discussion about merging those forks as-is, the number of successful merges is near zero. Of those who said 'hey, we did some cool stuff, here's our use cases and our initial thoughts on design. We have stuff that follows this design we can show but are otherwise happy to figure out the right design and build that", the number of successful merges is near 100%. So that's what was done.

maaku 11y ago

So where's the pull request?