please clarify criteria for gcc-4.0.0 patches

[Mark Mitchell]

Benjamin Kosnik wrote:

>>The patch you reference is in the same category: it is required for 
>>conformance to the ARM EABI.  Personally, I am very ambivalent about 
>>these patches.  I'd be just as happy to take them out again, if that 
>>would make people happier.  In fact, when I posted a message a while 
>>back about Stage 3, I specifically indicated that language and 
>>architecture issues would be to some extent delegated to their 
>>respective maintainers.  The COMDAT patch is not in this category, but 
>>the patch you reference is.  If you believe that my patch is too risky 
>>for Stage 3 devleopment in V3, let me know, and I will remove it.
>>    
>>
>
>I don't have a technical problem with this ARM EABI patch per se, I'm
>just confused about what I should be checking in.
>
>I guess ARM EABI work is considered a must-have feature for gcc-4.0.0?
>  
>
I expect that depends on who you ask. :-)

We don't have many must-have features; in fact, at this point, the only 
one we've really got is Objective-C++, because the SC promised Zem a 
shot at integrating it.  With my RM hat on, I certainly do not see ARM 
EABI as a must-have for GCC 4.0; if it's not done, we'll ship anyhow.  
However, I expect that the ARM maintainers will use the dispensation 
I've provided to back-end and language maintainers to accept EABI 
patches.  That's up to them, though.

>I still think you do a great job as chief cat herder! I'm just
>confused as to what is a legitimate fix, and what is something that is
>not appropriate for mainline, and hoping you'll help me come up with
>some kind of more rigorous criteria that I can use as a guide.
>
>From the development information, it seems like the changes allowed are
>1) documentation patches
>2) bug fixes
>3) new ports
>
>This seems sane to me. 
>  
>
Yes, that's correct -- except that for this release, we're doing an 
experimental process whereby backend and language maintainers have a 
little more leeway to accept patches that they think are very important, 
even if they don't quite fit in here.

>In addition, from your answer to the above, it looks like
>
>4) new features as required to meet feature goals for the release.
>  
>
I don't think that's accurate.  The projects list (based on the 
submissions that people provided) will be accepted if submitted before 
the deliver-by dates; otherwise, we'll do the release without those 
features.  So far, it looks like people are working hard to hit the 
target dates, so I am encouraged.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com