Changes between Version 1 and Version 2 of PlanToRemoveAlsaCode

Timestamp:

Sep 27, 2008, 4:27:49 AM (16 years ago)

Author:

Brendan Oakley

Comment:

Correct wording

PlanToRemoveAlsaCode

@@ -124 +124 @@
 One benefit that might be apparent is that this scheme lends itself well to a division of labor. One person can be testing with the latest drop from git, another porting the latest ALSA release, another adding more device support, another chasing bugs, etc., all without interfering with each other, and without waiting for someone else to finish something first. We can try all sorts of things with a common codebase, so that efforts are not dispersed across multiple branches, and we do not need to maintain multiple source trees on our local PC's.
 
-So this is a good way to reign in our multiple branches and get down to just one set of source. This is why I want to get 1.1.4GA done asap and out of the way. That's where I'll be focusing primarily until that's done. Of course, most of the remaining tickets for 1.1.4GA are things anyone could do, so although they are not very exciting, anyone eager to see it done could help.
+So this is a good way to rein in our multiple branches and get down to just one set of source. This is why I want to get 1.1.4GA done asap and out of the way. That's where I'll be focusing primarily until that's done. Of course, most of the remaining tickets for 1.1.4GA are things anyone could do, so although they are not very exciting, anyone eager to see it done could help.
 
 Initially I was thinking of making the new trunk a combination of the new build system, the non-ALSA code from uniaud32-2.0, with the new build setup, no alsa-kernel, and patches generated from alsa-resync1 and 2.0. But trying to do it all in one move can generate the serialization of arbitrary dependencies mentioned in Section II.A which causes unnecessary delays.
 
-So this will be the end-goal, but we'll apply it a little at a time. Uniaud32-2.0 will move to trunk after 1.1.4GA, and I'll start on the new build system, as a make option until it is ready, so we still have working code in the meantime, and no other efforts or goals are interfered with. Once we're happy with it we'll finalize the patches and make the switch, removing the alsa-kernel code. The spec is defined, and we can refine the details, so anyone else who is enthusiastic about this new build system can contribute; it doesn't have to just be me.
+So this will be the end-goal, but we'll apply it a little at a time. Uniaud32-2.0 will be merged with trunk after 1.1.4GA, and I'll start on the new build system, as a make option until it is ready, so we still have working code in the meantime, and no other efforts or goals are interfered with. Once we're happy with it we'll finalize the patches and make the switch, removing the alsa-kernel code. The spec is defined, and we can refine the details, so anyone else who is enthusiastic about this new build system can contribute; it doesn't have to just be me.
 
 I'm thinking of doing it by simply porting the makefiles as-is from alsa-driver to wmake, and then adding the capabilities I demo'ed in Section III.