On 21 January 2014 23:25, Chandler Carruth <chandlerc at google.com> wrote:> There are three commits I've made to Clang that I'd like to see in the 3.4 > release branch if for no other reason than to help out folks bootstrapping > on old Linux distributions with too-old installed versions of > GCC/libstdc++. These are r199632, r199633, and r199769. Let me know if you > can merge them or I should or how we can get a nice stable tree that folks > can check out and build as the first step of getting a bootstrap. >Hi Chandler, We haven't set a fixed date or anything, but if I got it right, those three patches are independent from any API changes, so they should be good to go on 3.4.1. Have you tried to apply them locally on a 3.4 branch? I think the first steps are to re-base and send a merge request to the commits list. We can follow from there... Tom, would be good to track all the patches that go in, so at least we have a way to update the change log. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140122/65653e47/attachment.html>
On Wed, Jan 22, 2014 at 12:46 AM, Renato Golin <renato.golin at linaro.org>wrote:> On 21 January 2014 23:25, Chandler Carruth <chandlerc at google.com> wrote: > >> There are three commits I've made to Clang that I'd like to see in the >> 3.4 release branch if for no other reason than to help out folks >> bootstrapping on old Linux distributions with too-old installed versions of >> GCC/libstdc++. These are r199632, r199633, and r199769. Let me know if you >> can merge them or I should or how we can get a nice stable tree that folks >> can check out and build as the first step of getting a bootstrap. >> > > Hi Chandler, > > We haven't set a fixed date or anything, but if I got it right, those > three patches are independent from any API changes, so they should be good > to go on 3.4.1. Have you tried to apply them locally on a 3.4 branch? I > think the first steps are to re-base and send a merge request to the > commits list. We can follow from there... >I don't think there is any need to rebase or send merge requests etc... They'll apply cleanly, or I can manually merge them if need be. The question is not how to merge them but *if* we should merge them, and if someone will create tags / release numbers to track this.> > Tom, would be good to track all the patches that go in, so at least we > have a way to update the change log. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140122/33056856/attachment.html>
On 22 January 2014 08:57, Chandler Carruth <chandlerc at google.com> wrote:> I don't think there is any need to rebase or send merge requests etc... > They'll apply cleanly, or I can manually merge them if need be. The > question is not how to merge them but *if* we should merge them, and if > someone will create tags / release numbers to track this. >That's what I meant by "merge request", not if they *would* apply, but if they *should* be applied. ;) It wasn't clear from my first email, I apologise, but I'm trying to come up with a process where we can easily detect, either now and later if you search the list, which patches are being proposed for back-porting. Today, we use "[PATCH]" for trunk, maybe we should have something like "[3.4.1]" or "[PATCH 3.4.1]" for the back-ports. The current release process is a bit confused in that we don't have a clear idea of which patches are being applied to each release candidate, because they're all spread out in the list without a clear identification, normally just copying the release manager, or waiting for him/her to pick it up from the discussion. I'd like to reduce this overhead by having clear semantics, so that the release manager could just filter for a specific pattern and be sure to have caught all back-port patches. That'd also make it easier to write the change log, just by filtering emails on a mailing list. Makes sense? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140122/8ddae3aa/attachment.html>