llvm dev - Nov 2014 - [LLVMdev] Out-of-tree passes (Was: LLVM Weekly - #43, Oct 27th 2014)

On Mon, Oct 27, 2014 at 9:41 AM, Philip Reames <listmail at
philipreames.com>
wrote:
>
> +1 on this.  I use Clang on the release schedule, but our LLVM work tracks
> TOT.  IMHO, trying to do anything else for an embedded compiler in a VM is
> pure folly and will lead to worlds of pain.
>
Nick Lewycky is currently doing Google's internal Clang releases, and we
actually tag them in svn over here:
http://llvm.org/viewvc/llvm-project/llvm/tags/google/stable/
http://llvm.org/viewvc/llvm-project/cfe/tags/google/stable/

I would only recommend using this release cadence for Clang if you have the
resources to stay up to date on fallout from warnings, C++ defect reports,
and such. I expect most users aren't willing to deal with that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141027/08a7d931/attachment.html>

Reid Kleckner wrote:
> On Mon, Oct 27, 2014 at 9:41 AM, Philip Reames
> <listmail at philipreames.com <mailto:listmail at
philipreames.com>> wrote:
>
>     +1 on this.  I use Clang on the release schedule, but our LLVM work
>     tracks TOT.  IMHO, trying to do anything else for an embedded
>     compiler in a VM is pure folly and will lead to worlds of pain.
>
>
> Nick Lewycky is currently doing Google's internal Clang releases, and
we
> actually tag them in svn over here:
> http://llvm.org/viewvc/llvm-project/llvm/tags/google/stable/
> http://llvm.org/viewvc/llvm-project/cfe/tags/google/stable/
>
> I would only recommend using this release cadence for Clang if you have
> the resources to stay up to date on fallout from warnings, C++ defect
> reports, and such. I expect most users aren't willing to deal with
that.
Basing your internal releases off of our stable tags is probably a good 
idea. We test aggressively, and since we try to update weekly, you can 
simply pick our latest tag whenever you're ready.

However, we recently started cherrypicking additional revisions on top 
of the ones we mark stable, and those aren't reflected upstream. If you 
have any ideas on how we should handle that, please let me know. It's on 
our todo list to do something about it, but I haven't figured out what 
that "something" should be yet. Note that we currently tag, not
branch,
and we probably don't want to branch all of llvm+clang+compiler_rt every 
week.

Nick

Why not branch instead of tag? Subversion makes this no more expensive.
Then we could track cherrypicks in it correctly.
On Nov 1, 2014 4:53 PM, "Nick Lewycky" <nicholas at mxc.ca>
wrote:
> Reid Kleckner wrote:
>
>> On Mon, Oct 27, 2014 at 9:41 AM, Philip Reames
>> <listmail at philipreames.com <mailto:listmail at
philipreames.com>> wrote:
>>
>>     +1 on this.  I use Clang on the release schedule, but our LLVM work
>>     tracks TOT.  IMHO, trying to do anything else for an embedded
>>     compiler in a VM is pure folly and will lead to worlds of pain.
>>
>>
>> Nick Lewycky is currently doing Google's internal Clang releases,
and we
>> actually tag them in svn over here:
>> http://llvm.org/viewvc/llvm-project/llvm/tags/google/stable/
>> http://llvm.org/viewvc/llvm-project/cfe/tags/google/stable/
>>
>> I would only recommend using this release cadence for Clang if you have
>> the resources to stay up to date on fallout from warnings, C++ defect
>> reports, and such. I expect most users aren't willing to deal with
that.
>>
>
> Basing your internal releases off of our stable tags is probably a good
> idea. We test aggressively, and since we try to update weekly, you can
> simply pick our latest tag whenever you're ready.
>
> However, we recently started cherrypicking additional revisions on top of
> the ones we mark stable, and those aren't reflected upstream. If you
have
> any ideas on how we should handle that, please let me know. It's on our
> todo list to do something about it, but I haven't figured out what that
> "something" should be yet. Note that we currently tag, not
branch, and we
> probably don't want to branch all of llvm+clang+compiler_rt every week.
>
> Nick
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141101/5be063a2/attachment.html>