"C. Bergström"
2013-Oct-30 01:11 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 10/30/13 03:17 AM, Chandler Carruth wrote:> On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com>> wrote: > > On 10/29/13 07:27 AM, Chandler Carruth wrote: > > On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" > <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.com> > <mailto:cbergstrom at pathscale.com > <mailto:cbergstrom at pathscale.com>>> wrote: > > fuzzy://How much "heads up" > > > One full release cycle, so approximately 6 months before a release > > If it's 3-6 months from *today* before something hits clang svn > trunk that should be enough time to address any problems. > > > No, it's 1 month, maybe 2 before something hits trunk, and over 6 > months before something hits a release.I'm objecting to 1 month for svn trunk - 2 months notice is even pushing it imho. 1) This is imho not the small change which it's being presented as 2) As someone else stated - there are projects tracking svn trunk and telling them to just stop doing that and follow the previous release is untenable without sufficient notice. (It just doesn't seem fair) May I humbly propose you create a c++11-development branch now/later/anytime and let people start using that. In parallel to that let people know that pieces of the c++11 branch will potentially start merging Feb 1st 2014. (roughly 3 months from today). This gives people time to review things before they hit trunk, test, discuss and experiment in a way that virtual discussions simply can't flush out. This hopefully won't hurt your target of the release-after-next using more modern toolchains and is *hopefully* a win-win in your view.
Richard Smith
2013-Oct-30 01:24 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On Tue, Oct 29, 2013 at 6:11 PM, "C. Bergström" <cbergstrom at pathscale.com>wrote:> On 10/30/13 03:17 AM, Chandler Carruth wrote: > >> On Mon, Oct 28, 2013 at 6:07 PM, "C. Bergström" <cbergstrom at pathscale.com<mailto: >> cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>> wrote: >> >> On 10/29/13 07:27 AM, Chandler Carruth wrote: >> >> On Mon, Oct 28, 2013 at 5:06 PM, "C. Bergström" >> <cbergstrom at pathscale.com <mailto:cbergstrom at pathscale.**com<cbergstrom at pathscale.com> >> > >> <mailto:cbergstrom at pathscale.**com <cbergstrom at pathscale.com> >> >> <mailto:cbergstrom at pathscale.**com <cbergstrom at pathscale.com>>>> >> wrote: >> >> fuzzy://How much "heads up" >> >> >> One full release cycle, so approximately 6 months before a release >> >> If it's 3-6 months from *today* before something hits clang svn >> trunk that should be enough time to address any problems. >> >> >> No, it's 1 month, maybe 2 before something hits trunk, and over 6 months >> before something hits a release. >> > I'm objecting to 1 month for svn trunk - 2 months notice is even pushing > it imho. > > 1) This is imho not the small change which it's being presented as > 2) As someone else stated - there are projects tracking svn trunk and > telling them to just stop doing that and follow the previous release is > untenable without sufficient notice. (It just doesn't seem fair) >If such projects exist and don't want to switch to C++11 mode, I think we should let them speak up, and not delay our own plans on the hypothesis that they exist. (Maybe they'll say that this is sufficient notice, maybe not, but we can't really guess.)> May I humbly propose you create a c++11-development branch > now/later/anytime and let people start using that. In parallel to that let > people know that pieces of the c++11 branch will potentially start merging > Feb 1st 2014. (roughly 3 months from today). This gives people time to > review things before they hit trunk, test, discuss and experiment in a way > that virtual discussions simply can't flush out. This hopefully won't hurt > your target of the release-after-next using more modern toolchains and is > *hopefully* a win-win in your view.I don't see how this helps anything. We don't /want/ to have the hassle of some people developing on a branch and some on trunk, so we would essentially have trunk stagnating and everyone developing on the branch. And then we'd merge the branch back again. Net result: exactly the same as if the people who aren't ready for c++11 stick with the 3.4 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131029/103db8b2/attachment.html>
"C. Bergström"
2013-Oct-30 01:42 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On 10/30/13 08:24 AM, Richard Smith wrote:> > May I humbly propose you create a c++11-development branch > now/later/anytime and let people start using that. In parallel to > that let people know that pieces of the c++11 branch will > potentially start merging Feb 1st 2014. (roughly 3 months from > today). This gives people time to review things before they hit > trunk, test, discuss and experiment in a way that virtual > discussions simply can't flush out. This hopefully won't hurt your > target of the release-after-next using more modern toolchains and > is *hopefully* a win-win in your view. > > > I don't see how this helps anything. We don't /want/ to have the > hassle of some people developing on a branch and some on trunk, so we > would essentially have trunk stagnating and everyone developing on the > branch. And then we'd merge the branch back again. Net result: exactly > the same as if the people who aren't ready for c++11 stick with the > 3.4 release.No its entirely not the same 1) Branch development is very common - I can't imagine *everyone* will use c++11 immediately and it causing some instant stall on trunk if a branch was made 2) As stated before - a branch lets a *real* discussion happen *before* it hits trunk. With any big feature change - isn't it best to be a little conservative instead of potentially break 1st and fix-it-later approach. Right now we're having a virtual discussion about things which may/may not happen. A branch with code is a tangible which can allow *real* testing and feedback. I think it's being worked on independently, but I haven't even seen an updated style guide. I don't even know what's exactly being proposed at this time. "c++11" is still fuzzy... clang/llvm has been around for 10 years?? Will waiting an extra month or doing some work in a branch 1st really kill anyone? Doesn't google and friends already use a branch model for development/test before it's merged.
Chris Lattner
2013-Oct-30 16:13 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
On Oct 29, 2013, at 6:11 PM, C. Bergström <cbergstrom at pathscale.com> wrote:>> No, it's 1 month, maybe 2 before something hits trunk, and over 6 months before something hits a release. > I'm objecting to 1 month for svn trunk - 2 months notice is even pushing it imho. > > 1) This is imho not the small change which it's being presented as > 2) As someone else stated - there are projects tracking svn trunk and telling them to just stop doing that and follow the previous release is untenable without sufficient notice. (It just doesn't seem fair) > > May I humbly propose you create a c++11-development branch now/later/anytime and let people start using that. In parallel to that let people know that pieces of the c++11 branch will potentially start merging Feb 1st 2014. (roughly 3 months from today). This gives people time to review things before they hit trunk, test, discuss and experiment in a way that virtual discussions simply can't flush out. This hopefully won't hurt your target of the release-after-next using more modern toolchains and is *hopefully* a win-win in your view.Umm, no. LLVM development happens on trunk, not on branches. Please see the developer policy if you are confused by this. I'm not sure what you're concerned about here, do you have any concrete problem in mind? The practical effect of this decision is that as soon as 3.4 branches, a *lot* of codebase churn will happen. All of which would be pointless to do on a branch. -Chris
dag at cray.com
2013-Nov-05 18:01 UTC
[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
Richard Smith <richard at metafoo.co.uk> writes:> I'm objecting to 1 month for svn trunk - 2 months notice is even > pushing it imho. > > 1) This is imho not the small change which it's being presented as > 2) As someone else stated - there are projects tracking svn trunk > and telling them to just stop doing that and follow the previous > release is untenable without sufficient notice. (It just doesn't > seem fair) > > If such projects exist and don't want to switch to C++11 mode, I think > we should let them speak up, and not delay our own plans on the > hypothesis that they exist. (Maybe they'll say that this is sufficient > notice, maybe not, but we can't really guess.)I'm not objecting to C++11 at all. I would love it! But I do agree that 1-2 months notice for a toolchain update on trunk is too short. I've been hammered countless times about not working off trunk and I am moving us in the direction of working off trunk (or at least something close to it). Short-notice toolchain changes on trunk are going to hamper that effort. It is a massive undertaking to test all of our compiler-related software once we change the toolchain used to build it. If there is consensus on which toolchain to move to about 4-6 months out, that seems like sufficient time to do testing. This means that for the next release, a decision on toolchain needs to be made pretty soon after cutting the previous release. -David
Maybe Matching Threads
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers
- [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers