[cfe-dev] [llvm-dev] LLVM Releases: Upstream vs. Downstream / Distros

[Daniel Berlin via cfe-dev]

>
>
> I'm particularly concerned with Android, because they not only have
> their own tree with heavily modified LLVM components (ex.
> Compiler-RT), but they also build differently and so their process are
> completely alien to ours. One of the key reasons why these things
> happened is because:
>


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.

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.

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'.

I don't think changing how stable works would change that, for a lot of
reasons (mostly around cost of ToT regressions, etc).

So i think you need to find a new motivating example :)


>  * They couldn't rely on our releases, as fixing bugs and back-porting
> wasn't a thing back then
>

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.



>  * They already had their own release schedule, so aligning with ours
> brought no extra benefit
>

This was not a concern.

 * We always expected people to work off trunk, and everyone had to
> create their own process
>

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.

>
> I don't want to change how people work, just to add one more valid way
> of working, which is most stable for upstream releases. :)
>


Full validation every 6 weeks is just not possible. But a multiple of
> that, say every 3~4 months, could be much easier to work around.


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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160512/d4a37888/attachment.html>