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"

It sounds like a random wrong-code bug, which do happen.

There is just a timeframe where random fixes are not good.

Was 4.6.3 "intended for public consumption"?

Be reasonable.

Reply via email to