dist-git kernel
by Roland McGrath
The upshot of the scary, scary migration lossage was that Jesse and I
became positive we would be eaten by a grue, and just ran away.
The old migration was all bad. We don't know why, and we don't really want
to know, but might resume an attempt to find out later on after the giant
dist-git wildfire is more under control generally.
If nobody cares, we probably just won't bother with it. The old pkgs cvs
repository exists read-only and, I presume, will exist forever at least in
some accessible archive somewhere. If that is enough to satisfy needs to
look at old history, then we can just start forgetting all we ever knew
about CVS quickly.
If we want to recover the old threads of history and integrate them with
the new git history that starts today, then we can suffer the great pain of
figuring out what the hell to do. If we get some cvs->git guru to sort out
the pure conversion of the old cvs repositories, then we'll have perhaps as
many as two options. The option that's easier to be sure about is that we
can then 'git rebase' our post- G-day commits on top of the new conversion.
That has the downside of invalidating all the old commit ids and repos that
we all have in our checkouts, and any commit ids that koji stored or
whatever. The other option that might exist is some git magic to knit
together the separate old and new histories. I vaguely recall something
like that exists, but I actually have no idea how to do it or what it
really makes possible.
So, what we have now is:
remotes/origin/HEAD -> origin/master
remotes/origin/f10/master 64ba2e5 Initial setup of the repo
remotes/origin/f11/master 64ba2e5 Initial setup of the repo
remotes/origin/f12/master 2f82dda initial srpm import
remotes/origin/f13/master 3494df0 initial srpm import
remotes/origin/f14/master 7a32965 initial srpm import
remotes/origin/f7/master 64ba2e5 Initial setup of the repo
remotes/origin/f8/master 64ba2e5 Initial setup of the repo
remotes/origin/f9/master 64ba2e5 Initial setup of the repo
remotes/origin/master 7f2b706 Restore TODO file.
remotes/origin/olpc2/master 64ba2e5 Initial setup of the repo
All those 64ba2e5's are actually just empty, we have not actually imported
anything for those branches yet.
The f1[234]/master branches were made with 'fedpkg import' of the result of
'make srpm' from each old CVS pseudo-branch's HEAD. (I think--Jesse
actually did it all.) So it should have what was last committed in CVS
even if it wasn't ever built.
On master, from which f14/master only just today branched, I've just put:
377da6d First crack at adaptation to dist-git.
7f2b706 Restore TODO file.
11487c5 Restore README.txt, scripts.
The first one is the .spec and Makefile patches I posted yesterday.
I didn't use any of the Makefile stuff, but I figure we might want
it sitting there until we clean it up into some scripts/ stuff or whatever
we are going to do. (IMHO almost none of that belongs in make, though
Makefile.config is probably OK.)
The second is adding back the TODO file verbatim. I just assumed we're
actually still using that. Then I noticed that scripts/ was gone too,
and put that back. Some scripts and README.txt are probably out of date
talking about cvs and make stuff that doesn't exist.
You should get right on that.
Then I merged master back onto f14/master, so they are now the same.
Until we actually doing f15 separately, these are both the same and
it doesn't really matter which branch you use for commits. Just make
sure it's the same one every time, and merge the other one in first.
There should not be any non-fast-forward merges until we really want
to work separately on f15.
I figure we should spend a few days kicking the tires on f14 and/or rawhide
builds and clean up the scripts. Then we can apply the same .spec and
script stuff to the f13 branch to get it building again.
Thanks,
Roland
13 years, 8 months
- 3
- 6
kernel.spec updated to let prepped source trees coexist in a single git directory
by Chuck Ebbert
I've added the %{dist} tag to the name of the top-level source
directory so that source trees from different branches don't overwrite
each other. For example, the tree for f14 is now called
kernel-2.6.35.fc14 instead of kernel-2.6.35 .
Identical vanilla directories within those trees will be automatically
hardlinked to each other whenever possible, but there is one caveat:
If you change the contents of a vanilla- directory so it no longer
matches the upstream source, those changes can silently propagate into
other source trees. So don't do that. Always make a copy and change
that.
13 years, 8 months
- 1
- 0