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.
>>>> 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
>>> (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
>> 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.
In that case I'd like to add a note to the caveats section in wwwdocs
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.