[alsa-devel] Merging alsa-driver and alsa-kmirror to one GIT repo
Hi all,
I believe, it's time to manage only one GIT repository for the alsa-driver package now. The merge has benefits mainly for the end users - bisecting may work, the correlation between kernel sources and our out-of-kernel build framework becomes more strong.
I merged the alsa-driver and alsa-kmirror repos with full history. I also added some code changes to enable the "build-in" mirror tree in Makefile and gitcompile from v1.0.18 (but I don't think that it will be used).
The structure of new repository is similar, but the kernel mirrored code is located in the mirror/ subdirectory. The paths are exactly same as in the Linux kernel tree, so possible patches can be applied without any path modifications. Of course, we may create a bash script to do proper and full cherry-picks between kernel and mirrored trees (comments, author, dates).
New temporary repository has name alsa-driver.new:
http://git.alsa-project.org/?p=alsa-driver.new.git;a=summary
The another difference is that the releases are now branches not tags. It allows me to do quick fixes out of the standard development or separate the main development in the release time window (to not include some very new code). The previous branches won't contain probably any additional commits, but it's probably better to play with only one reference scheme.
I think that the change from alsa-driver.git to alsa-driver.new.git should be quick. Please, report any objections or acks now.
Schedule: When accepted, I will rename the original alsa-driver.git repository to alsa-driver.old.git and move alsa-driver.new.git to alsa-driver.git quickly.
1.0.26 release: This was my last big change (with the ALSA server upgrade) which blocked me to do the 1.0.26 release. I'm going to create new release after the repos switch ASAP.
Jaroslav
At Tue, 24 Jul 2012 15:17:57 +0200, Jaroslav Kysela wrote:
Hi all,
I believe, it's time to manage only one GIT repository for the alsa-driver package now. The merge has benefits mainly for the end users
- bisecting may work, the correlation between kernel sources and our
out-of-kernel build framework becomes more strong.
The biggest question from my side is how to handle it in future.
IMHO, the current alsa-driver tree structure isn't in the best form. Alternatively, we can change the alsa-driver tree into the standard linux-kernel tree form: i.e. linux-kernel plus the extra alsa-driver build stubs. In that way, you can keep the consistency by pulling the main kernel part easily into alsa-driver tree if the change in the build stub is required.
Of course, it means some directory changes would be required. But git pull is much saner than cherry-picking each commit to a different tree (alsa-kmirror) with directory/path conversions.
The downside is that creating a traditional alsa-driver release tarball won't be straightforward but need some script. But it shouldn't be too hard.
Also, the release management of alsa-driver is another question. It's pretty obvious that 99% of changes nowadays are in the driver. And we are working rather together with the kernel release cycle more than the ALSA release. Thus it's more natural to release the alsa-driver along the kernel release cycle.
That is, we may release alsa-driver-3.5 now containing the same stuff for 3.5 kernel but also with the external build stubs. It no longer needs to stick with the old "ALSA version", IMO. The ALSA version is rather confusing for both users and developers since the same version appears in the different kernels with pretty different ALSA driver codes actually.
Thoughts?
thanks,
Takashi
I merged the alsa-driver and alsa-kmirror repos with full history. I also added some code changes to enable the "build-in" mirror tree in Makefile and gitcompile from v1.0.18 (but I don't think that it will be used).
The structure of new repository is similar, but the kernel mirrored code is located in the mirror/ subdirectory. The paths are exactly same as in the Linux kernel tree, so possible patches can be applied without any path modifications. Of course, we may create a bash script to do proper and full cherry-picks between kernel and mirrored trees (comments, author, dates).
New temporary repository has name alsa-driver.new:
http://git.alsa-project.org/?p=alsa-driver.new.git;a=summary
The another difference is that the releases are now branches not tags. It allows me to do quick fixes out of the standard development or separate the main development in the release time window (to not include some very new code). The previous branches won't contain probably any additional commits, but it's probably better to play with only one reference scheme.
I think that the change from alsa-driver.git to alsa-driver.new.git should be quick. Please, report any objections or acks now.
Schedule: When accepted, I will rename the original alsa-driver.git repository to alsa-driver.old.git and move alsa-driver.new.git to alsa-driver.git quickly.
1.0.26 release: This was my last big change (with the ALSA server upgrade) which blocked me to do the 1.0.26 release. I'm going to create new release after the repos switch ASAP.
Jaroslav-- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.
Date 24.7.2012 15:34, Takashi Iwai wrote:
At Tue, 24 Jul 2012 15:17:57 +0200, Jaroslav Kysela wrote:
Hi all,
I believe, it's time to manage only one GIT repository for the alsa-driver package now. The merge has benefits mainly for the end users
- bisecting may work, the correlation between kernel sources and our
out-of-kernel build framework becomes more strong.
The biggest question from my side is how to handle it in future.
IMHO, the current alsa-driver tree structure isn't in the best form. Alternatively, we can change the alsa-driver tree into the standard linux-kernel tree form: i.e. linux-kernel plus the extra alsa-driver build stubs. In that way, you can keep the consistency by pulling the main kernel part easily into alsa-driver tree if the change in the build stub is required.
Of course, it means some directory changes would be required. But git pull is much saner than cherry-picking each commit to a different tree (alsa-kmirror) with directory/path conversions.
Although the git merging features are very good, I do not prefer to build something on top of this development type. The cross patch management may reveal also some auto-merge mistakes (I hit few). Also, working with the whole Linux tree is not necessary for the developement. I mostly debug things on top of the distro specific kernel. I don't understand the requirement to fetch 99% of unused code to build the sound driver for another kernel.
The downside is that creating a traditional alsa-driver release tarball won't be straightforward but need some script. But it shouldn't be too hard.
Also, the release management of alsa-driver is another question. It's pretty obvious that 99% of changes nowadays are in the driver. And we are working rather together with the kernel release cycle more than the ALSA release. Thus it's more natural to release the alsa-driver along the kernel release cycle.
That is, we may release alsa-driver-3.5 now containing the same stuff for 3.5 kernel but also with the external build stubs. It no longer needs to stick with the old "ALSA version", IMO. The ALSA version is rather confusing for both users and developers since the same version appears in the different kernels with pretty different ALSA driver codes actually.
Yes, the kernel build-in ALSA version should be changed (to something like 'k3.5' or removed).
I am not sure, if it's necessary to relate the alsa-driver releases to the kernel releases. From my perspective, it's just a snapshot, which may be more tested for the compilation on more different kernels. The standard ALSA versioning make sense for this, too. Timestamps show the relationship nicely.
Jaroslav
I merged the alsa-driver and alsa-kmirror repos with full history. I also added some code changes to enable the "build-in" mirror tree in Makefile and gitcompile from v1.0.18 (but I don't think that it will be used).
The structure of new repository is similar, but the kernel mirrored code is located in the mirror/ subdirectory. The paths are exactly same as in the Linux kernel tree, so possible patches can be applied without any path modifications. Of course, we may create a bash script to do proper and full cherry-picks between kernel and mirrored trees (comments, author, dates).
New temporary repository has name alsa-driver.new:
http://git.alsa-project.org/?p=alsa-driver.new.git;a=summary
The another difference is that the releases are now branches not tags. It allows me to do quick fixes out of the standard development or separate the main development in the release time window (to not include some very new code). The previous branches won't contain probably any additional commits, but it's probably better to play with only one reference scheme.
I think that the change from alsa-driver.git to alsa-driver.new.git should be quick. Please, report any objections or acks now.
Schedule: When accepted, I will rename the original alsa-driver.git repository to alsa-driver.old.git and move alsa-driver.new.git to alsa-driver.git quickly.
1.0.26 release: This was my last big change (with the ALSA server upgrade) which blocked me to do the 1.0.26 release. I'm going to create new release after the repos switch ASAP.
Jaroslav-- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.
Jaroslav,
This re-organise of git repos has currently broken the link from the project website to alsa-info.sh:
http://www.alsa-project.org/alsa-info.sh this looks like a 302 redirect to http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=utils/alsa-inf... currently giving a 404
it should point to: http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=alsa/utils/als... think ? who has the access required to fix this?
Grant
participants (3)
-
Grant Diffey -
Jaroslav Kysela -
Takashi Iwai