<div dir="ltr">On Wed, Apr 3, 2013 at 11:39 AM, Óscar Fuentes <span dir="ltr"><<a href="mailto:ofv@wanadoo.es" target="_blank">ofv@wanadoo.es</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> writes:<br>
<br>
> The largest barrier that I see, which nobody seems to have mentioned, is<br>
> the community culture.<br>
</div>[snip]<br>
<br>
Well, the plan I described assumed "zero collaboration from the<br>
developers" for exactly the reasons you mentioned.<br></blockquote><div><br></div><div style>Indeed. I was just trying to bring it up as an explicit issue rather than assuming a priori that it was insurmountable.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
IMO it is possible to bring a "maintenance branch" which is preferable<br>
to the development branch for those LLVM users searching for stability,<br>
without disturbing current development process. After all, you only need<br>
to make it a more attractive option than jumping into ToT tracking.<br></blockquote><div><br></div><div style>I'm not sure how difficult it actually is to follow ToT compared to one huge pain when upgrading for our full releases. I think it would be valuable to obtain feedback from projects that rely on LLVM as to how they go about integrating LLVM into their project and how our releases (and potentially dot-releases) would integrate into their development process.</div>
<div style><br></div><div style>I believe that the way that the Rust language is doing things is to keep a separate fork of LLVM on github, where they put in the patches to work around bugs that they find. Their main repository then keeps this LLVM fork pinned on particular commits ofthe fork (using git's submodule functionality). This has the benefit that they can easily cherry-pick patches onto their fork whenever they want (or backport, if necessary). They can then merge in major releases at their leisure, and I believe that git is smart enough to recognize the cherry-picked patches and merge with no hassles.</div>
<div style>If multiple projects were to adopt this kind of "structured" approach to depending on LLVM, I think that what is effectively a "stable branch" could be achieved with just a tiny bit of coordination and sharing. Each project fixes the issues that immediately affect them and share their cherry-picking/backporting with other interested projects. This would require minimal manpower from within the LLVM project proper (possibly just one person in contact with the various dependent projects to make sure that everyone is on the same page; a sort of "ambassador") and we would know that the branch is fixing real issues that have come up in practice with no effort wasted cherry-picking/backporting patches for a "theoretical" stability gain.</div>
<div style><br></div><div style>i.e., we could empower our users to contribute the effort that they are *already* putting into cherry-picking/backporting to maintain a "stable community branch" for us.</div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Also, it's not clear that we have the infrastructure to test these dot<br>
> releases on all our supported platforms. IMHO, without that, it's hard to<br>
> have much confidence in the dot release, and I wouldn't want to put out<br>
> "LLVM 3.2.1, tested on Linux only".<br>
<br>
</div>If you cover a large fraction of the users, why not?<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>I think that for a "personal" stable branch it would be an appropriate policy.</div><div><br></div><div>However, for an "official LLVM-endorsed and supported" stable branch, such a policy could potentially alienate the 1-"large fraction" of the users that you don't cover, and those are exactly the users that we *need* in order to help LLVM support their platforms better. This is a general social phenomenon: larger and more-public organizational units need to be more careful to ensure that they are not perceived as alienating or discriminating. E.g. if you are serving dinner to close friends, nobody is going to blame you for not having e.g. a vegetarian or gluten-free option. But you can be sure that if the White House holds a dinner, they are going to ensure that they have a vegetarian or gluten-free option.</div>
<div><br></div><div style>So it might make sense for the a "stable branch" to be initially an independent effort by a group of interested individuals who are willing to put the time into maintaining it, rather than immediately an "official" stable branch as in Tom's proposal. This will allow building out infrastructure and automation for the stable release process and platform support. For example, coming up with a clear procedure for making a platform one of the tested platforms for the stable release (ideally, it should be as simple as donating a machine running that platform and keeping an eye on it).</div>
<div style>If this effort shows that a stable branch delivers real value to our users, for example if some linux distribution decides that it is sufficiently valuable to package the stable dot-releases, or we receive lots of positive feedback from our users who are using the stable branches, then it should be straightforward to brand it with an official LLVM sticker.</div>
<div> <br></div><div style>-- Sean Silva</div></div></div></div>