Should back-ports cc the mailing lists for the area? (was Re: [7u8] Request for approval: 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h)

[Seán Coffey]

+1 on Edvard's suggestion then. Giving the original author notification 
of the proposed backport first will help avoid the problem described. 
There's also the option to request extra reviews at 7u approval time 
also if needed (as per 7u ground rules)

Alan makes a good point around the original jdk8 author not always being 
the correct one to ask. In that case, should the list of engineers to be 
notified of backport extend to author & original reviewers ? I conscious 
of not wanting to spam the various -dev aliases with each backport 
request that may be occurring with 8 -> 7u.

regards,
Sean.

On 07/08/2012 14:25, Alan Bateman wrote:
> On 07/08/2012 13:51, Edvard Wendelin wrote:
>> Hi,
>>
>> When I've been working on backports that I'm not the original author 
>> of, I have always asked the engineer if the fix is suitable to 
>> backport or not. Instead of having to CC the entire group I'd like to 
>> suggest the following alternative rule:
>>
>> If you are not the original author, make sure both of you are in 
>> agreement that the fix is suitable for backport before requesting for 
>> approval on the mailing list.
>>
>> I think the most common use case by far is that the same engineer 
>> takes the fix to 8 and 7u and in that case we shouldn't add more 
>> processes.
>>
> I don't want to waste any time on this but I think the concern is 
> mostly with cases where the original author doesn't have history in 
> the specific area where the change is. He/she gets a review from 
> someone in that area for jdk8 and then gets approval (!= code review) 
> for the change for jdk7u-dev as that's where they are mostly 
> interested in. In that case the original reviewers/experts don't 
> always see it or only see it after it's in jdk7u-dev. I think this is 
> what Phil's original complaint was about. I think Andrew and David's 
> concerns are slightly different and covered in the previous thread.
>
> -Alan.