Bastian, I'm really sorry I've taken so long to look at this.
On Tue, 2015-09-08 at 22:52 +0200, Bastian Blank wrote:
> Moin
>
> During the linux packaging BoF at DebConf, Ben asked for usefull
> upstream source handling. No compeling ones were mentioned.
>
> Some years ago (yes, years), I proposed some schema based on submodules,
> but never got around to actually implement it. I finally managed to do
> an initial implementation. It currently lives in the linux.git in
> branch waldi/submodule.
>
> Main principles:
> - source of each featureset is a submodule, using version specific
> branches
> - orig source via version specific tag
So genorig.py would be replaced with 'git archive'?
> Workflow:
> - New upstream version
> - Rebase old tag on top of new upstream, tag it with the new version
There are no tags in the repository you created. Can you add one as an
example?
Do you think we would tag when updating to a new upstream version, or
only when making the first upload with a new orig tarball (allowing for
further DFSG changes before uploading)?
> - Rebase old main featureset branch on top of new orig tag as new
> branch
> - Rebase old other featureset branches on top of new main featureset
> branch or replace with new base and create new branch
> - Record new top commits and update changelog in main repo
That's a lot of rebasing, though not so different from what we do now
to refresh the patch series. Presumably we would add a script to
support this and ensure it is all done properly?
The submodules are checked out with detached heads by default. Is your
intent that we would override this?
I tried this:
$ cd source/orig
$ git checkout orig/4.2-rc8
For some reason, this deleted upstream files in the working tree -
maybe because of the '*' in .gitignore?
...
Branch orig/4.2-rc8 set up to track remote branch orig/4.2-rc8 from origin.
Switched to a new branch 'orig/4.2-rc8'
$ git reset --hard
...
$ git checkout -b orig/4.3
Switched to a new branch 'orig/4.3'
$ git fetch ~/src/linux refs/tags/v4.3:refs/tags/v4.3
This fetched all tags; maybe I should have just fetched to FETCH_HEAD?
...
$ git rebase v4.3
First, rewinding head to replay your work on top of it...
Applying: Remove microcode patches for mgsuvd (not enabled in Debian configs)
Applying: dvb-usb-af9005: remove, mark as broken
Applying: vs6624: remove, mark as broken
Applying: Remove and mark as broken: cops
Applying: video: Remove nvidiafb and rivafb
Applying: Remove the entire firmware directory
Applying: Remove: ft1000
Applying: Remove: Non-free RFC
$ cd ../none
$ git checkout none/4.2-rc8
...
Branch none/4.2-rc8 set up to track remote branch none/4.2-rc8 from origin.
Switched to a new branch 'none/4.2-rc8'
$ git reset --hard
...
$ git checkout -b none/4.3
Switched to a new branch 'none/4.3'
$ git fetch ../orig orig/4.3
From ../orig
* branch orig/4.3 -> FETCH_HEAD
$ git rebase --onto=FETCH_HEAD origin/orig/4.2-rc8
This rebase took a while, but was definitely easier than rebasing with
quilt. There are no featuresets to deal with currently.
...
$ cd ../..
$ sed -i 's/4.2-rc8/4.3/' .gitmodules
$ emacsclient debian/changelog
Waiting for Emacs...
$ git commit -a -m 'Update to 4.3'
$ git push --set-upstream alioth benh/submodule
...
$ cd source/orig
$ git push --set-upstream origin orig/4.3
This pushed a whole load of tags too. WTF?
...
$ cd ../none
$ git push --set-upstream origin none/4.3
...
Is it possible to combine those push commands? Is this something else
we would need to script?
> - Cherry pick patch
> - (Make sure the submodules are on the correct branch, otherwise it
> will be hard to push changes or they will go to incorrect locations)
> - Cherry pick patch
> - Merge changes into all derived featuresets, if any
Rather than rebasing?
> - Record new top commits and update changelog in main repo
So that's two commits rather than one at present. A little annoying.
> There are some things not yet implemented or different in my preview:
> - debuild from the repo tree does not yet work, the rules are missing
> the special directory definitions
> - orig is also a submodule
>
> Please take a look and let me know what you think about this variant.
> Most likely I've forgotten something, but I don't know what it is.
What I like:
1. Rebasing is easier
2. I can log, diff, etc. through our changes and upstream changes
What I don't like:
3. Pushing is more complicated
4. Cherry-picking is more complicated
5. Git working directory looks different from unpacked source package
6. It's not possible to see the history of one of our patches
(3) and (4) definitely need to be addressed, either by documentation
(if I'm missing some git feature or config) or by scripting.
I think I can live with (5) and (6). For (6), maybe we should start
putting Change-Ids in our changes so that it would be possible to find
all versions using 'git log --tags=debian --grep=...'
Ben.
--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.Attachment:
signature.asc
Description: This is a digitally signed message part