<div dir="ltr"><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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
I'm particularly concerned with Android, because they not only have<br>
their own tree with heavily modified LLVM components (ex.<br>
Compiler-RT), but they also build differently and so their process are<br>
completely alien to ours. One of the key reasons why these things<br>
happened is because:<br></blockquote><div><br></div><div><br></div><div>Errr, Stephen has spoken up here, but my folks are in contact with android folks pretty much every week, and I don't think what you are stating is correct on a lot of fronts.</div><div><br></div><div>I'm also a little concerned about you speaking for android here, instead of android speaking for android here :P.  I'll be frank: I don't think you know enough details of internal history of android to state, affirmatively, why these things happened for android, and what you are suggesting  is, AFAIK, not correct or accurate.</div><div><br></div><div>So if android is your particular concern here, i can pretty much state that android LLVM is on a release process close to the rest of Google, which is 'follow TOT very closely'.</div><div><br></div><div>I don't think changing how stable works would change that, for a lot of reasons (mostly around cost of ToT regressions, etc).</div><div><br></div><div>So i think you need to find a new motivating example :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
 * They couldn't rely on our releases, as fixing bugs and back-porting<br>
wasn't a thing back then<br></blockquote><div><br></div><div>This is, AFAIK,  not accurate. Renderscript has its own history not worth getting into, but outside of the renderscript version, LLVM in android is very close to TOT. It has been as long as someone really cared about it. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> * They already had their own release schedule, so aligning with ours<br>
brought no extra benefit<br></blockquote><div><br></div><div>This was not a concern. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
 * We always expected people to work off trunk, and everyone had to<br>
create their own process<br></blockquote><div><br></div><div>Android mostly shares a process with the rest of Google these days, in the sense that they rely on  validation we do in other contexts.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
I don't want to change how people work, just to add one more valid way<br>
of working, which is most stable for upstream releases. :)<br></blockquote><div><br></div><span class="im" style="font-size:12.8px"><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Full validation every 6 weeks is just not possible. But a multiple of<br></span><span style="font-size:12.8px">that, say every 3~4 months, could be much easier to work around.</span></blockquote><div><br>FWIW: Full validation is already done on a faster-than-6 week time schedule, so i'm also going to suggest that your "just not possible" claim is false :)</div><div><br></div><div><br></div><div> </div></div></div></div>