linux-firmware, Maverick edition

[Chase Douglas]

On Tue, 2010-05-25 at 12:20 -0600, Tim Gardner wrote:
> On 05/25/2010 09:57 AM, Chase Douglas wrote:
> > Tim,
> >
> > I've rebased the lucid linux-firmware branch onto the current upstream
> > tree [1]. The end result can be found in my linux-firmware tree in the
> > maverick branch [2]. Please review. I can provide a source package for
> > you to upload when you find it acceptable.
> >
> > As an overview, I squashed all the debian packaging commits, except the
> > lucid changelog commits, to be the first commit of the rebase. I then
> > squashed all the lucid changelog commits to the last commit and added a
> > new version (1.35) for the rebase. I squashed these to the end because
> > it made more sense for the changelog commit referencing new firmware to
> > follow the commits that introduced the firmware. This seemed like a
> > reasonable approach to me, but I'm open to suggestions on how to do this
> > better. There were two or three commits that we had cherry-picked, so I
> > deleted those commits altogether during the rebase.
> >
> > This first version for Maverick includes just the rebase against
> > upstream. After this is done I will start working on merging firmware
> > from medibuntu's alsa-firmware to linux-firmware{,-nonfree}.
> >
> > Thanks,
> >
> > -- Chase
> >
> > [1]
> > git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git
> > [2] git://kernel.ubuntu.com/cndougla/linux-firmware.git
> >
> 
> Actually, I prefer to maintain history from the previous release so that 
> its easier to figure out the delta from upstream. I've created a 
> linux-firmware maverick branch and uploaded the first pass, though I 
> forgot to note in the changelog that I rebased against the upstream 
> repo. I corrected that in the repository, but didn't upload with a new 
> changelog.

If we keep the history exactly as is, we end up with weirdness like:

http://kernel.ubuntu.com/git?p=ubuntu/linux-firmware.git;a=commit;h=856e8335b2806f36eb861441b99cf22b399ba6fc
http://kernel.ubuntu.com/git?p=ubuntu/linux-firmware.git;a=commit;h=a39fca5fa17b51d8c493ab2783cf37db61dd7763

It would seem based on the commit msg that the commit adds the firmware,
but it doesn't because we rebased on top of the upstream that already
has the firmware. Now we've got two commits both saying they are for the
exact same firmware and two entries in WHENCE for the same firmware.
However, if we delete the commit, the literal git history becomes less
meaningful. This is one reason I squashed the changelog commits.

One other reason I had for squashing the changelog commits was that we
could easily create a pull request from the end of the debian packaging
commits to the beginning of the changelog commits that could be sent
upstream. If we leave the history as is we have to cherry-pick out
firmware commits in between the debian packaging commits.

In my head I was thinking we could send a pull request at the beginning
of each cycle for all the firmware we added from the last cycle
upstream. Rebasing in this manner would help keep the process more
manageable.

-- Chase