On Tue, Mar 6, 2012 at 12:13 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > Richard Guenther wrote: >> On Mon, Mar 5, 2012 at 6:54 PM, Georg-Johann Lay <a...@gjlay.de> wrote: >>> Richard Guenther wrote: >>>> On Mon, Mar 5, 2012 at 6:15 PM, Georg-Johann Lay <a...@gjlay.de> wrote: >>>>> Richard Guenther wrote: >>>>>> On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay <a...@gjlay.de> wrote: >>>>>>> Richard Guenther wrote: >>>>>>>> On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay <a...@gjlay.de> wrote: >>>>>>>>> Richard Guenther wrote: >>>>>>>>> >>>>>>>>>> All commits to the 4.7 branch need explicit release manager >>>>>>>>>> approval. AVR >>>>>>>>>> isn't primary/secondary so please do not change anything before is >>>>>>>>>> released 4.7.0 for it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Richard. >>>>>>>>> What is the exact procedure in that case? >>>>>>>>> Wait until approve from release manager in that case? >>>>>>>>> Who is the release manager, and should I CC for such changes? >>>>>>>>> Or just hope the patch is not overseen. >>>>>>>> The exact procedure is to do bugfixing during stage3/4, for release >>>>>>>> blockers >>>>>>>> that pop up after a release candidate is created (like now), CC a >>>>>>>> release >>>>>>>> manager (Jakub, me, Joseph) for patches that you like to get in even >>>>>>>> though the branch is frozen. Usually only bugs that prevent basic >>>>>>>> functionality >>>>>>>> (like building a target) can be fixed at this point, for everything >>>>>>>> else you have >>>>>>>> to wait until after 4.7.0 is released and the branch opens again for >>>>>>>> regression >>>>>>>> fixes. >>>>>>>> >>>>>>>> Richard. >>>>>>> I was not aware that the 4.7.0 branch is completely frozen for the next >>>>>>> 3 >>>>>>> weeks; I thought the usual rules for backporting patches do apply... >>>>>> No they don't. How would you expect that testing a release candidate >>>>>> would >>>>>> work if we put in any not strictly necessary changes? That would make a >>>>>> release candidate quite pointless. >>>>>> >>>>>>> The patch changes only in libgcc/config/avr and gcc/config/avr >>>>>>> >>>>>>> The patch does not fix a blocker in the sense that without it avr >>>>>>> cannot be >>>>>>> built, but the changes are essential. >>>>>> Surely not so essential as that they cannot be put in place to make the >>>>>> 4.7.1 >>>>>> release then. >>>>> Okay. >>>>> >>>>> In that case I'd like to add a note to the caveats section in wwwdocs >>>>> >>>>> ./gcc-4.7/changes.html >>>>> >>>>> that the avr-gcc 4.7.0 is not intended for public consumption and because >>>>> of >>>>> developer shortage at least 4.7.1 should be used. >>>> Completely unusable? It looks like it only affects a subset of all >>>> devices: >>>> "To read from flash on devices with more than 64KiB of flash" >>> The patch fixes more problems than indicated by log message's PR. >>> >>>> It sounds like a random wrong-code bug, which do happen. >>> Yes they happen. But if the defect is so severe that the code is effectively >>> useless, the compiler is useless. >>> >>> That is not a problem if it is clearly stated and people don't waste days to >>> set up and distribute avr toolchains that are useless. It would simply be >>> not >>> fair to let them waste their time and to hold back that knowledge. >>> >>>> There is just a timeframe where random fixes are not good. >>> This is not a problem. Just inform the potential users about the defect. >>> >>>> Was 4.6.3 "intended for public consumption"? >>> Yes. >> >> So, what patch regressed state from 4.6.3 to the present completely unusable >> compiler? Why is it not appropriate to revert that instead? Why is the >> bug not marked as regression? The bug sounds as if it only applies to >> XMEGA+EBI (whatever that means). > > Yes, the problems all affect new features. > >> Can you split the patch and separate out the fix for the PR if the patch >> does not only fix that PR? > > You are right, it's definitely better to break up the patch into the > individual > PRs if there is no way to get a patch in 4.7.0, anyway. > > As far as I can see, only new features/architectures are non-functional to > that > postponing them to 4.7.1 is an option.
Thanks. So it seems only those new features are "unusable" then, you might simply announce them for 4.7.1 only (changes.html will have a sub-section covering changes for 4.7.1). Richard. > Johann >
