| Submitter | Khem Raj |
|---|---|
| Date | June 13, 2011, 4:03 a.m. |
| Message ID | <cover.1307937636.git.raj.khem@gmail.com> |
| Download | mbox |
| Permalink | /patch/5683/ |
| State | New, archived |
| Headers | show |
Pull-request
git://git.openembedded.org/openembedded-core-contrib kraj/gcc-4.6-updateComments
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? p.
Op 13 jun 2011, om 10:51 heeft Phil Blundell het volgende geschreven: > 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? We used the svn approach with gcc 4.5 and I liked it very, very much. regards, Koen
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 :)
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. p.
Op 14 jun 2011, om 11:28 heeft Phil Blundell het volgende geschreven: > 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 wasn't being sarcastic, I really like it very, very much.
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. Cheers, Richard
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 This patch doesn't seem to have bumped PR on gcc-4.6.0.bb even though the SRC_URI has changed. Was that intentional? p.
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