Rebase prep work

[Tim Gardner]

Andy Whitcroft wrote:
> I have been thinking about when Karmic has released and we start prep
> for the LL kernel.  It appears time for a fold-down of the various
> patches to simplify the git history of the commits.  To that end I would
> expect us to naturally squash all commits to debian/ into a single
> commit which would be the 2.6.NN-0.0 commit as normal.  I would then
> expect that we would review the remaining drivers and squash those to a
> single commit per driver, dropping those completely that have been added
> and subsequently removed.
> 
> While reviewing the drivers with this in mind I noted that there are a
> number of commits which add or remove more than one driver and do so in
> such a way its hard to tell what they add or remove.  It would be much
> more helpful if we had a one driver per commit approach.
> 
> With the desire to squash the debian/ into a single commit it also
> likely would be handy to always add drivers in a commit and then enable
> them in a separate [Config] commit after.  When removing disable them in
> the config and then remove them in a second commit.  Thus the rebase
> process can squash the config updates with the rest of debian/ and we
> can then drop any paired add/remove commits.
> 
> Looking at the history there are a few commits which break this approach
> and it would be relativly simple to clean these up while we are in the
> rebase phase of the tree.  I list them below with the proposed logical
> replacements for them.
> 
> If people concur this change make sense then I can push them into the
> current tree.  Obviously the overall effect top to bottom is an
> identicle tree.
> 
> UBUNTU: ubuntu: Add misc drivers from hardy lum
> 	UBUNTU: Add ubuntu/misc
> 	UBUNTU: ubuntu: Add appleir driver from hardy lum
> 	UBUNTU: ubuntu: Add dm-bbr driver from hardy lum
> 	UBUNTU: ubuntu: Add acerhk driver from hardy lum
> 	UBUNTU: ubuntu: Add lmpcm_usb driver from hardy lum
> 	UBUNTU: ubuntu: Add ThinkPad drivers from hardy lum
> UBUNTU: Dropped ubuntu/misc/acerhk
> 	Revert "UBUNTU: ubuntu: Add acerhk driver from hardy lum"
> 
> UBUNTU: ubuntu: Add ov511 and bt-sco drivers
> 	UBUNTU: add ubuntu/media directory
> 	UBUNTU: ubuntu: Add bt-sco driver
> 	UBUNTU: ubuntu: Add ov511 driver
> UBUNTU: Remove snd-bt-sco ubuntu driver
> 	Revert "UBUNTU: ubuntu: Add bt-sco driver"
> 
> UBUNTU: ubuntu: Add acx, prism2_usb wireless drivers
> 	UBUNTU: ubuntu: Add acx wireless driver
> 	UBUNTU: ubuntu: Add prism2_usb wireless driver
> UBUNTU: [Config] Dropped ubuntu/misc/wireless/acx
> 	Revert "UBUNTU: ubuntu: Add acx wireless driver"
> 
> UBUNTU: Removed ubuntu/e1000e
> 	Revert "UBUNTU: SAUCE: e1000e: Map NV RAM dynamically only when needed."
> 	Revert "UBUNTU: ubuntu: e1000e: Upgraded module to 0.4.1.7"
> 
> UBUNTU: Dropped drivers obsoleted by staging
> 	UBUNTU: [Config] disable drivers obsoleted by staging
> 	Revert "UBUNTU: ubuntu: Added atl2 driver"
> 	Revert "UBUNTU: ubuntu: Added et131x driver"
> 	Revert "UBUNTU: ubuntu: Add heci driver 3.2.0.24"
> 	Revert "UBUNTU: ubuntu: Add at76 driver to build"
> 	Revert "UBUNTU: SAUCE: Fix Oops in wlan_setup"
> 	Revert "UBUNTU: ubuntu: Add prism2_usb wireless driver"
> 	Revert "UBUNTU: ubuntu: Add dm-bbr driver from hardy lum"
> 	UBUNTU: dropped qc-usb driver
> 
> Comments?
> 
> -apw
> 

I think this will be difficult to do without encountering some real
config issues, besides running the risk of hosing some of the topic
branches. The way we manage config files is the root of the problem,
simply because _all_ of the config files are generated (and can change
radically from one config change to the next). Now that we have a
hierarchical arrangement, I'm leaning towards a more manual config
management process. We'd still run updateconfigs just to make sure the
configs are sane, but we won't combine and sort them automatically every
time. This likely deserves a bit of a chat at next week's sprint.

I think Loic also has some ideas about it.

rtg
-- 
Tim Gardner tim.gardner at canonical.com