This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Merging glibc-ports repo
> 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?
That sounds generally reasonable to me. I would like to see the plan
modified in a couple of simple ways.
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,
and copious tags made in that repo beforehand so that anybody with
an old ports checkout with local modifications can do 'git checkout
end-of-ports' to pin their checkout to a state with all the files
still there, and then collect their local changes easily into
patches with various git commands to move them over to their main
libc checkout. This can be delayed as long as necessary for
everyone to have coped with the transition. But the state we leave
in glibc-ports.git#master for ever after should contain no real
files whatsoever, not any final state of all those files. There
will be for ever after a tag at that final-but-all-still-there
state so that anybody can recover it trivially.
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.
During the interregnum, people can of course continue to post
patches, use private branches to share, etc.
Thanks,
Roland