All of lore.kernel.org
 help / color / mirror / Atom feed
From: Khem Raj <raj.khem@gmail.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/1] Upgrade gcc 4.6.0 to latest on FSF 4.6 branch
Date: Tue, 14 Jun 2011 19:33:43 -0700	[thread overview]
Message-ID: <4DF81A07.3090502@gmail.com> (raw)
In-Reply-To: <1308055023.15712.333.camel@rex>

On 06/14/2011 05:37 AM, Richard Purdie wrote:
> On Tue, 2011-06-14 at 10:28 +0100, Phil Blundell wrote:
>> On Mon, 2011-06-13 at 10:12 -0700, Khem Raj wrote:
>>> On Mon, Jun 13, 2011 at 1:51 AM, Phil Blundell<pb@pbcl.net>  wrote:
>>>> On Sun, 2011-06-12 at 21:03 -0700, Khem Raj wrote:
>>>>> This patch brings in new patches from gcc 4.6 FSF branch
>>>>> And refreshes the headers of existing backported patches
>>>>> to not have git patch numbers in comments
>>>>>
>>>>> I am not sending the patch itself to mailing list due to its
>>>>> large size so please review it on the contrib tree itself
>>>>>
>>>>
>>>> Would we not be better off just pulling the tip of the 4.6 branch from
>>>> FSF SVN, rather than having to keep all these patches in git?
>>>>
>>>
>>> there is dislike for this approach in oe-core. As the release point is preferred
>>> I suggested to drop the minor release number and call the recipes 4.6
>>> and use SVN
>>> REVs to track the recipe updates but it did not fly :)
>>
>> Where does that dislike come from?  Koen did make a comment about having
>> liked svn checkouts for 4.5 "very, very much" but I couldn't quite
>> figure out whether he was being sarcastic or not and, if so, what
>> exactly his objection was.
>>
>> I could understand there being a preference for individual patchsets if
>> we were just going to cherry-pick carefully selected bugfixes from the
>> branch and patch them in.  But, if we're going to take the approach of
>> just importing everything from the branch en masse, it seems like
>> keeping them as patches is just making more work for ourselves.
>>
>> We're using svn checkouts for eglibc, which seems to be working well
>> enough and hasn't provoked any particular outrage that I noticed.
>
> I think it was my dislike that Khem is referring to. I was under the
> impression that we were going to be more selective that just taking
> everything (e.g. the translation updates probably aren't essential to
> us).
>
> I realise its easier to just take everything though and if we are going
> to do that it probably does make sense to use svn directly. I'll take a
> patch to do that.

What goes into release branches of gcc are strictly bug fixes only. So 
its safe to get them all

I will prepare a patch for it.

>
> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




  reply	other threads:[~2011-06-15  2:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-13  4:03 [PATCH 0/1] Upgrade gcc 4.6.0 to latest on FSF 4.6 branch Khem Raj
2011-06-13  8:51 ` Phil Blundell
2011-06-13  9:01   ` Koen Kooi
2011-06-13 17:12   ` Khem Raj
2011-06-14  9:28     ` Phil Blundell
2011-06-14  9:43       ` Koen Kooi
2011-06-14 12:37       ` Richard Purdie
2011-06-15  2:33         ` Khem Raj [this message]
2011-06-14 15:10 ` Phil Blundell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DF81A07.3090502@gmail.com \
    --to=raj.khem@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.