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).


> Johann

Reply via email to