Re: Merging glibc-ports repo

[Carlos O'Donell <carlos_odonell at mentor dot com>]

On 6/23/2012 3:15 AM, Allan McRae wrote:
> On 23/06/12 00:46, Joseph S. Myers wrote:
>> On Fri, 22 Jun 2012, Allan McRae wrote:
>>
>>> One workaround would be if this merge was done _immediately_ after the
>>> glibc-2.16 tag.  Then the commit bringing in glibc-ports could just be
>>> given its own tag. Not ideal, but it would only have to be used for a
>>> single release.
>>
>> I think that would be reasonable:
>>
>> * Freeze master.
>>
>> * Make the release from master, as has been generally done before (rather 
>> than branching first), with both libc and ports getting glibc-2.16 tags on 
>> master.
>>
>> * Create the 2.16 branches of both libc and ports with the 2.16 tags as 
>> branchpoint.
>>
>> * Get the ports history into the ports directory of libc's master, as 
>> discussed (without changing master in the ports repository).
>>
>> * Tag the new state of libc's repository as glibc-2.16-merged or similar - 
>> it should be exactly what you get if you put 2.16 ports in a ports 
>> subdirectory of 2.16 libc.
>>
>> * Add a README.ports-moved-to-libc file to ports master and change the 
>> hooks to disallow subsequent commits to ports master.
>>
>> * Do all the usual post-release-branch steps for libc master (updating 
>> version numbers / development state).
> 
> 
> That sounds a good plan to me.
> 
> @Carlos: Are you happy doing this as port of your glibc-2.16 release
> process?

Allan,

Yes. I can do this as part of the 2.16 release process.

Could you please start a wiki page for the transition if we haven't already?

Roland, Community,

Any objections to do doing the merge as outlined above?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026