This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Merging glibc-ports repo
On Mon, 25 Jun 2012, Roland McGrath wrote:
> 1. At the end of everything, the master branch of ports should contain
> nothing but the README-moved file. This can be delayed a while,
I don't see any more need for this than there was for doing "cvs rm" on
the files in the old CVS repositories. Those still have the state as of
conversion to git, and that's fine, and more convenient for checking CVS
history for things messed up in the course of the conversion than having
such a "cvs rm" done would have been. Now, git makes it much easier to
look at the old state of a tree than CVS, and removing files after a month
or two should be fairly harmless - but only useful if the old repository
is actually confusing people.
> 2. There should be an absolute moratorium on all commits to the master
> branch in the libc repository for at least a day or two before and
> after the merge work. When the people doing the legwork think it's
> all set, they should leave a 'before' branch and an 'after' branch
> that are the state of master before and after the repo merge. Then
> there must be a period where all the major active contributors can
> verify that everything looks sane, at least a full day, and as much
> longer as it takes for everbody relevant to post their assent.
> Only then will 'after' become 'master' and normal operations
> resume.
The moratorium and branch with what will become "master" make sense - but
I'd think the merge work and creation of that branch could happen
immediately after the release is created from master - I don't think we
need a gap between release creation and creating the merged branch. (But
I imagine Carlos will want to call the moratorium when he's ready to do
the final release steps, to avoid any unexpected commits while the release
steps are in progress.)
--
Joseph S. Myers
joseph@codesourcery.com