[alsa-devel] HG vs GIT
Hi,
it seems that GIT matured somewhat. git-push has been implemneted. It was main reason to not use GIT when we made decision between HG and GIT. As we could have potential problems with branches in HG repository, I would like to consider a switch to GIT althought it means some changes in my scripts on ALSA server and my ksync tool. I just successfully tried (a bit modified hg-to-git.py script) and it seems to be working properly. Any objections?
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Thu, 7 Feb 2008 10:37:29 +0100 (CET), Jaroslav Kysela wrote:
Hi,
it seems that GIT matured somewhat. git-push has been implemneted. It was main reason to not use GIT when we made decision between HG and GIT.
Hm, I thought it simply because you prefer python...
As we could have potential problems with branches in HG repository, I would like to consider a switch to GIT althought it means some changes in my scripts on ALSA server and my ksync tool. I just successfully tried (a bit modified hg-to-git.py script) and it seems to be working properly. Any objections?
I don't mind to move to git, but IMHO, it's no urgent issue. Let's get things out (e.g. concentrate on 2.6.25 merge) right now, and then change the infrastructure in the right way.
BTW, one big annoying thing is that developers have no complete kernel tree to access, and thus the patches that touch outside the ALSA subdirectory cannot be merged easily. People often send patches fixing together with OSS, etc, and I had to skip them. So, frankly, I'd love to have an access to the whole kernel tree. But, OTOH, this would make harder for other naive guys to give it a try because they need to download the big linux kernel tree git.
Maybe we can think reversely. Keep the kernel git tree as the primary development tree and generate the subset as the alsa-kernel package from the kernel tree automatically. In this way, you can avoid also sign-off messes, too.
In this scheme, you don't have to stick with stgit. The normal git can handle patches well enough (via occasional rebase), and it's much much faster than stgit. Of course, stgit is still good for small number of patches, but it's not true for shared devel trees.
Just my $0.02.
Takashi
On Feb 7, 2008 6:27 AM, Takashi Iwai tiwai@suse.de wrote:
BTW, one big annoying thing is that developers have no complete kernel tree to access, and thus the patches that touch outside the ALSA subdirectory cannot be merged easily. People often send patches fixing together with OSS, etc, and I had to skip them. So, frankly, I'd love to have an access to the whole kernel tree. But, OTOH, this would make harder for other naive guys to give it a try because they need to download the big linux kernel tree git.
I was just wondering about this the other day.. I don't think using kernel git trees would put anyone off. Anyone working on a sound card driver would most likely already be familiar with using git w/ the upstream kernel anyway.
My own personal alsa use is in kernels with no loadable module support, so I can't use the standalone package to build modules anyway. I need the code integrated into the tree and I just do it by hand right now.
I've tinkered with libata (git) as well as alsa, and I think having it in git makes it a bit easier when dealing with upstream updates and merging.
-Andrew
At Thu, 7 Feb 2008 06:45:10 -0500, Andrew Paprocki wrote:
On Feb 7, 2008 6:27 AM, Takashi Iwai tiwai@suse.de wrote:
BTW, one big annoying thing is that developers have no complete kernel tree to access, and thus the patches that touch outside the ALSA subdirectory cannot be merged easily. People often send patches fixing together with OSS, etc, and I had to skip them. So, frankly, I'd love to have an access to the whole kernel tree. But, OTOH, this would make harder for other naive guys to give it a try because they need to download the big linux kernel tree git.
I was just wondering about this the other day.. I don't think using kernel git trees would put anyone off. Anyone working on a sound card driver would most likely already be familiar with using git w/ the upstream kernel anyway.
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
Takashi
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 06:45:10 -0500, Andrew Paprocki wrote:
On Feb 7, 2008 6:27 AM, Takashi Iwai tiwai@suse.de wrote:
BTW, one big annoying thing is that developers have no complete kernel tree to access, and thus the patches that touch outside the ALSA subdirectory cannot be merged easily. People often send patches fixing together with OSS, etc, and I had to skip them. So, frankly, I'd love to have an access to the whole kernel tree. But, OTOH, this would make harder for other naive guys to give it a try because they need to download the big linux kernel tree git.
I was just wondering about this the other day.. I don't think using kernel git trees would put anyone off. Anyone working on a sound card driver would most likely already be familiar with using git w/ the upstream kernel anyway.
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
I have an idea to create a web interface generating the alsa-kernel like tree on the fly (with some caching, of course). It might also apply for all ALSA packages. It would be quite nice to point users to very recent code and not to wait for daily tarballs.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Thu, 7 Feb 2008 13:19:49 +0100 (CET), Jaroslav Kysela wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 06:45:10 -0500, Andrew Paprocki wrote:
On Feb 7, 2008 6:27 AM, Takashi Iwai tiwai@suse.de wrote:
BTW, one big annoying thing is that developers have no complete kernel tree to access, and thus the patches that touch outside the ALSA subdirectory cannot be merged easily. People often send patches fixing together with OSS, etc, and I had to skip them. So, frankly, I'd love to have an access to the whole kernel tree. But, OTOH, this would make harder for other naive guys to give it a try because they need to download the big linux kernel tree git.
I was just wondering about this the other day.. I don't think using kernel git trees would put anyone off. Anyone working on a sound card driver would most likely already be familiar with using git w/ the upstream kernel anyway.
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
I have an idea to create a web interface generating the alsa-kernel like tree on the fly (with some caching, of course). It might also apply for all ALSA packages. It would be quite nice to point users to very recent code and not to wait for daily tarballs.
This would be helpful indeed.
Takashi
On Thu, 7 Feb 2008, Takashi Iwai wrote:
I was just wondering about this the other day.. I don't think using kernel git trees would put anyone off. Anyone working on a sound card driver would most likely already be familiar with using git w/ the upstream kernel anyway.
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
You'll certainly get a lot fewer users of the latest driver code if they have to download, compile and install a entire new kernel. There are plenty of people who will install new drivers, but won't even consider switching from the kernel their distro came with.
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
The media drivers on linuxtv.org work similar to ALSA, with an Hg repository of just the drivers that's designed to build out of the kernel tree (and work with multiple kernel versions). There is an hg-menu interface on the server that lets developers create, delete and clone repositories. Each developer has their own set of repositories that they own, with Mauro pulling from those into the master repository. This way you can clone repos for branching, and you don't have multiple developers commiting directly to the same repository.
At Thu, 7 Feb 2008 05:10:27 -0800 (PST), Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
I was just wondering about this the other day.. I don't think using kernel git trees would put anyone off. Anyone working on a sound card driver would most likely already be familiar with using git w/ the upstream kernel anyway.
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
You'll certainly get a lot fewer users of the latest driver code if they have to download, compile and install a entire new kernel. There are plenty of people who will install new drivers, but won't even consider switching from the kernel their distro came with.
Yep.
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
Hm, what's the problem to pull alsa.git tree to your own working tree?
The media drivers on linuxtv.org work similar to ALSA, with an Hg repository of just the drivers that's designed to build out of the kernel tree (and work with multiple kernel versions). There is an hg-menu interface on the server that lets developers create, delete and clone repositories. Each developer has their own set of repositories that they own, with Mauro pulling from those into the master repository. This way you can clone repos for branching, and you don't have multiple developers commiting directly to the same repository.
Creating developer's repo freely would be great, indeed.
Takashi
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:10:27 -0800 (PST),
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
Hm, what's the problem to pull alsa.git tree to your own working tree?
How do I test the driver if it's compiled with the kernel in the alsa.git tree? I want to compile the driver against the kernel I'm running now.
At Thu, 7 Feb 2008 05:41:57 -0800 (PST), Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:10:27 -0800 (PST),
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
Hm, what's the problem to pull alsa.git tree to your own working tree?
How do I test the driver if it's compiled with the kernel in the alsa.git tree? I want to compile the driver against the kernel I'm running now.
Well, I don't get your point. "git-pull alsa.git" onto your current kernel tree and make. Then you have the latest ALSA drivers for your current system...
Of course, a subset tree like the current alsa-kernel would be much more handy. That's why I suggest to create the subset tree automatically from the linux kernel tree.
Takashi
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:41:57 -0800 (PST), Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:10:27 -0800 (PST),
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
Hm, what's the problem to pull alsa.git tree to your own working tree?
How do I test the driver if it's compiled with the kernel in the alsa.git tree? I want to compile the driver against the kernel I'm running now.
Well, I don't get your point. "git-pull alsa.git" onto your current kernel tree and make. Then you have the latest ALSA drivers for your current system...
Pull cannot be used. You'll pull also Linus's changes in tree with this command (which might not be wanted).
We'll provide a GNU patch interface to patch your tree as required hidding used SCM system, of course.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Thu, 7 Feb 2008 14:52:43 +0100 (CET), Jaroslav Kysela wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:41:57 -0800 (PST), Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:10:27 -0800 (PST),
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
Hm, what's the problem to pull alsa.git tree to your own working tree?
How do I test the driver if it's compiled with the kernel in the alsa.git tree? I want to compile the driver against the kernel I'm running now.
Well, I don't get your point. "git-pull alsa.git" onto your current kernel tree and make. Then you have the latest ALSA drivers for your current system...
Pull cannot be used. You'll pull also Linus's changes in tree with this command (which might not be wanted).
Ah, OK, I didn't think that your current tree is behind the ALSA tree. But surely there must be an easy way to do that. At easiest, I'd make a diff of alsa-git.tree to the upstream and apply it over the local tree.
(BTW I think we don't track the Linus tree so often once. A rebase would be required ocasionally but it should be rare.)
We'll provide a GNU patch interface to patch your tree as required hidding used SCM system, of course.
It's something like alsa-git.patch in mm tree, right?
Takashi
On Thu, 7 Feb 2008, Takashi Iwai wrote:
We'll provide a GNU patch interface to patch your tree as required hidding used SCM system, of course.
It's something like alsa-git.patch in mm tree, right?
Yes, something like this. But I would like to produce such patches in a dynamic way (I think only limited developers would like to get them).
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 14:52:43 +0100 (CET),
How do I test the driver if it's compiled with the kernel in the alsa.git tree? I want to compile the driver against the kernel I'm running now.
Well, I don't get your point. "git-pull alsa.git" onto your current kernel tree and make. Then you have the latest ALSA drivers for your current system...
Pull cannot be used. You'll pull also Linus's changes in tree with this command (which might not be wanted).
Ah, OK, I didn't think that your current tree is behind the ALSA tree. But surely there must be an easy way to do that. At easiest, I'd make a diff of alsa-git.tree to the upstream and apply it over the local tree.
It would have to be behind the current tree, unless you reboot multiple times per day.
The problem with an out of tree codebase extracted from git (or Hg), is that once extracted you couldn't use ALSA's SCM on it. E.g., generating nice patches based on current head, or pulling and merging recent patches in with your current work.
I have a dozen different v4l-dvb Hg branches aka repositories on my system, for different features or projects, etc. What branches are for. Some are months old. I can work on any one of those branches, compile, load, and test the drivers, and push new changes to that branch, without rebooting. I can do the same with ALSA too in fact, though the ALSA out of tree build system is less convenient. I'm not going to reboot five times a day. I only have one computer, and I'm not going to chance my recoding of the new episode of Lost tonight getting messed up because of a problem in a one day old kernel that hasn't been tested.
I don't have to reboot between 2.6.21 or 2.6.25-rc1 to work on a different branch.
At Thu, 7 Feb 2008 07:49:39 -0800 (PST), Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 14:52:43 +0100 (CET),
How do I test the driver if it's compiled with the kernel in the alsa.git tree? I want to compile the driver against the kernel I'm running now.
Well, I don't get your point. "git-pull alsa.git" onto your current kernel tree and make. Then you have the latest ALSA drivers for your current system...
Pull cannot be used. You'll pull also Linus's changes in tree with this command (which might not be wanted).
Ah, OK, I didn't think that your current tree is behind the ALSA tree. But surely there must be an easy way to do that. At easiest, I'd make a diff of alsa-git.tree to the upstream and apply it over the local tree.
It would have to be behind the current tree, unless you reboot multiple times per day.
What a shame :)
The problem with an out of tree codebase extracted from git (or Hg), is that once extracted you couldn't use ALSA's SCM on it. E.g., generating nice patches based on current head, or pulling and merging recent patches in with your current work.
It's possible to extract and merge patches nicely with git. I just pointed the "easiest" way to get the latest code. There must be a better way.
Takashi
On Thu, Feb 07, 2008 at 05:03:03PM +0100, Takashi Iwai wrote:
Trent Piepho wrote:
The problem with an out of tree codebase extracted from git (or Hg), is that once extracted you couldn't use ALSA's SCM on it. E.g., generating nice patches based on current head, or pulling and merging recent patches in with your current work.
It's possible to extract and merge patches nicely with git. I just pointed the "easiest" way to get the latest code. There must be a better way.
I have to confess that I've not tried this with ALSA but for osme other areas of the kernel I've succesfully used the out of tree build support in kbuild to allow me to work on drivers while running a distro kernel. I'd change into the directory with the module source and say something like:
make M=${PWD} -C /lib/modules/$(uname -r)/build
to build against the installed kernel headers and config.
This does break if the current code depends on any changes under include/ which would be more of a problem for some bits ALSA than for most of the things I've tried this approach with - it's more suitable for individual drivers than something like ALSA core, for example.
At Thu, 7 Feb 2008 19:46:24 +0000, Mark Brown wrote:
On Thu, Feb 07, 2008 at 05:03:03PM +0100, Takashi Iwai wrote:
Trent Piepho wrote:
The problem with an out of tree codebase extracted from git (or Hg), is that once extracted you couldn't use ALSA's SCM on it. E.g., generating nice patches based on current head, or pulling and merging recent patches in with your current work.
It's possible to extract and merge patches nicely with git. I just pointed the "easiest" way to get the latest code. There must be a better way.
I have to confess that I've not tried this with ALSA but for osme other areas of the kernel I've succesfully used the out of tree build support in kbuild to allow me to work on drivers while running a distro kernel. I'd change into the directory with the module source and say something like:
make M=${PWD} -C /lib/modules/$(uname -r)/build
to build against the installed kernel headers and config.
This does break if the current code depends on any changes under include/ which would be more of a problem for some bits ALSA than for most of the things I've tried this approach with - it's more suitable for individual drivers than something like ALSA core, for example.
The external build itself is relatively easy. We have already such stuff in alsa-driver tree. Just needs a slight change to remap the directories properly in linux kernel tree instead of alsa-kernel tree.
What I mentioned is to merge changesets properly from one tree to another old tree. Maybe a kind of cherry picking would do that.
Takashi
On Thu, Feb 07, 2008 at 09:36:15PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
make M=${PWD} -C /lib/modules/$(uname -r)/build
The external build itself is relatively easy. We have already such stuff in alsa-driver tree. Just needs a slight change to remap the directories properly in linux kernel tree instead of alsa-kernel tree.
What I mentioned is to merge changesets properly from one tree to another old tree. Maybe a kind of cherry picking would do that.
The thing I was thinking of above was taking a vanilla kernel tree and building a subdirectory of that as though it were out of tree. This lets you use a vanilla git tree with the headers and config of a second kernel tree (eg, a distro supplied one), meaning that from a revision control point of view there's nothing fancy going on.
On Fri, 2008-02-08 at 00:42 +0000, Mark Brown wrote:
On Thu, Feb 07, 2008 at 09:36:15PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
make M=${PWD} -C /lib/modules/$(uname -r)/build
The external build itself is relatively easy. We have already such stuff in alsa-driver tree. Just needs a slight change to remap the directories properly in linux kernel tree instead of alsa-kernel tree.
What I mentioned is to merge changesets properly from one tree to another old tree. Maybe a kind of cherry picking would do that.
The thing I was thinking of above was taking a vanilla kernel tree and building a subdirectory of that as though it were out of tree. This lets you use a vanilla git tree with the headers and config of a second kernel tree (eg, a distro supplied one), meaning that from a revision control point of view there's nothing fancy going on.
One problem with this approach is insuring that you get the current alsa headers. If these were kept in the alsa-driver tree, it might be more manageable. The alsa-driver tree is specifically for doing out-of-tree builds, and includes workarounds for older kernels that would be missed otherwise.
One reason for building against older distro kernels is that corporations may continuously roll out new hardware on older distro's. They need to be able to back port some drivers for hardware compatibility without breaking their image. Where I work, the corporate IT image is Suse 9.3 based (ancient in Linux terms). I believe it came with alsa 1.0.6 or 1.0.7. Won't work on the newer HD Audio hardware, guaranteed.
My current work involves multiple spins of Ubuntu, RedFlag, and to a small degree Fedora. This is where the out-of-tree environment really works well.
On Thu, 2008-02-07 at 14:48 +0100, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:41:57 -0800 (PST), Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 05:10:27 -0800 (PST),
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
Hm, what's the problem to pull alsa.git tree to your own working tree?
How do I test the driver if it's compiled with the kernel in the alsa.git tree? I want to compile the driver against the kernel I'm running now.
Well, I don't get your point. "git-pull alsa.git" onto your current kernel tree and make. Then you have the latest ALSA drivers for your current system...
Of course, a subset tree like the current alsa-kernel would be much more handy. That's why I suggest to create the subset tree automatically from the linux kernel tree.
I do. I for one am using a canned distro (Mandriva 2008). I don't mess with the kernel tree at all. I just build and test alsa by combining the alsa-driver and alsa-kernel HG trees (same thing the daily snapshot does).
The advantage of this is I can test this snapshot on multiple distributions without having to try to find a kernel git tree for each distro (some barely give you the kernel headers package to build on).
For the work I do, having multiple kernel trees to test on would be difficult.
Tobin Davis
Darling: the popular form of address used in speaking to a member of the opposite sex whose name you cannot at the moment remember. -- Oliver Herford
On Thu, Feb 07, 2008 at 05:10:27AM -0800, Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
You'll certainly get a lot fewer users of the latest driver code if they have to download, compile and install a entire new kernel. There are plenty of people who will install new drivers, but won't even consider switching from the kernel their distro came with.
Judging from what I've seen on the IRC channels I hang around on I get the impression that relatively few people doing this on a user level (typically people with shiny new laptops and so on) are using hg to access the drivers - they mostly seem to be using either the snapshot or release tarballs to update their existing kernels. So long as those are available in a similar form I would expect these users would be unaffected.
It would also be a huge PITA for developers who work on multiple sub-systems. If I want to make a patch for an alsa driver, I have to reboot into an alsa kernel? I try to go a few months between rebooting.
This use case is fairly well served by git - it is being used by enough subsystems for people to be running into it a lot. The support for multiple remotes makes it relatively easy to have a git tree which works with changes from multiple places and cherry-pick makes it relatively straightforward to move changes between branches for submission.
At Thu, 7 Feb 2008 15:00:22 +0000, Mark Brown wrote:
On Thu, Feb 07, 2008 at 05:10:27AM -0800, Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
You'll certainly get a lot fewer users of the latest driver code if they have to download, compile and install a entire new kernel. There are plenty of people who will install new drivers, but won't even consider switching from the kernel their distro came with.
Judging from what I've seen on the IRC channels I hang around on I get the impression that relatively few people doing this on a user level (typically people with shiny new laptops and so on) are using hg to access the drivers - they mostly seem to be using either the snapshot or release tarballs to update their existing kernels. So long as those are available in a similar form I would expect these users would be unaffected.
I have a same impression. I started providing daily snapshot tarballs because so many people avoid HG when I requested for testing.
A snapshot tarball (of each commit at best) would be a convenient solution for most of users, I guess.
Takashi
On Thu, 7 Feb 2008, Mark Brown wrote:
On Thu, Feb 07, 2008 at 05:10:27AM -0800, Trent Piepho wrote:
On Thu, 7 Feb 2008, Takashi Iwai wrote:
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
You'll certainly get a lot fewer users of the latest driver code if they have to download, compile and install a entire new kernel. There are plenty of people who will install new drivers, but won't even consider switching from the kernel their distro came with.
Judging from what I've seen on the IRC channels I hang around on I get the impression that relatively few people doing this on a user level (typically people with shiny new laptops and so on) are using hg to access the drivers - they mostly seem to be using either the snapshot or
That could be because ALSA does "releases". For the media drivers, there are no releases. If you want the latest drivers (or maybe some developer's branch for a certain piece of hardware that's still under development), you grab the code from Hg. Certainly a lot of people just grab the tip tarball with wget and don't use hg clone, but they have the same codebase that developers using Hg have.
On Thu, Feb 07, 2008 at 08:03:57AM -0800, Trent Piepho wrote:
On Thu, 7 Feb 2008, Mark Brown wrote:
Judging from what I've seen on the IRC channels I hang around on I get the impression that relatively few people doing this on a user level (typically people with shiny new laptops and so on) are using hg to access the drivers - they mostly seem to be using either the snapshot or
grab the code from Hg. Certainly a lot of people just grab the tip tarball with wget and don't use hg clone, but they have the same codebase that developers using Hg have.
Sure, that's my point, pretty much - for a user grabbing a tarball it's immaterial where the contents of the taball come from so long as they correspond to the software they want. A change from hg to git wouldn't affect them so long as the tarballs continue to be provided and provide access to current ALSA code.
If your concern is more that people using the tarball will be using it in combination with an unknown distribution kernel rather than the rest of the tree (assuming ALSA decides to change to git and go for a full kernel tree, which I hope happens) then surely this isn't much of a change from the current situation?
Hello,
please find enclosed a simple patch for listing AK4114 regs in proc.
Thanks a lot.
Pavel Hofman.
Signed-off-by: Pavel Hofman dustin@seznam.cz
At Sun, 10 Feb 2008 21:17:08 +0100, Pavel Hofman wrote:
+static void snd_ak4114_proc_regs_read(struct snd_info_entry *entry,
struct snd_info_buffer *buffer)+{
- struct ak4114 *ak4114 = (struct ak4114 *)entry->private_data;
You don't need this cast.
Otherwise the patch looks fine and was applied to HG tree. Thanks.
Takashi
Takashi Iwai wrote:
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
I don't think there are many people who really care about this. I personally don't know any. In fact, ALSA is the only kernel subsystem I know that works the way it does now.
At Thu, 07 Feb 2008 09:22:04 -0600, Timur Tabi wrote:
Takashi Iwai wrote:
Right, if you are a developer, it's fine (and even better). But, my concern is that the whole linux kernel tree might be too heavy for some casual user who just wants to try the latest version of ALSA driver... "Download 50MB and use 350MB disk space just for a single fix? Hell, no!"
I don't think there are many people who really care about this. I personally don't know any. In fact, ALSA is the only kernel subsystem I know that works the way it does now.
It depends on the definition of "people". Developers don't care, of course. But users, more specifically bug reporters/testers, do care. It'll surprise you how many reporters don't use SCM in the debug sessions when you see ALSA bugtracks. They really prefer an easy installable tarball.
Takashi
On Thu, 7 Feb 2008, Takashi Iwai wrote:
At Thu, 7 Feb 2008 10:37:29 +0100 (CET), Jaroslav Kysela wrote:
Hi,
it seems that GIT matured somewhat. git-push has been implemneted. It was main reason to not use GIT when we made decision between HG and GIT.
Hm, I thought it simply because you prefer python...
Yes, it was one reason. But I must also admit, that GIT evolution seems to be faster than Marcurial.
As we could have potential problems with branches in HG repository, I would like to consider a switch to GIT althought it means some changes in my scripts on ALSA server and my ksync tool. I just successfully tried (a bit modified hg-to-git.py script) and it seems to be working properly. Any objections?
I don't mind to move to git, but IMHO, it's no urgent issue. Let's get things out (e.g. concentrate on 2.6.25 merge) right now, and then change the infrastructure in the right way.
BTW, one big annoying thing is that developers have no complete kernel tree to access, and thus the patches that touch outside the ALSA subdirectory cannot be merged easily. People often send patches fixing together with OSS, etc, and I had to skip them. So, frankly, I'd love to have an access to the whole kernel tree. But, OTOH, this would make harder for other naive guys to give it a try because they need to download the big linux kernel tree git.
Maybe we can think reversely. Keep the kernel git tree as the primary development tree and generate the subset as the alsa-kernel package from the kernel tree automatically. In this way, you can avoid also sign-off messes, too.
In this scheme, you don't have to stick with stgit. The normal git can handle patches well enough (via occasional rebase), and it's much much faster than stgit. Of course, stgit is still good for small number of patches, but it's not true for shared devel trees.
As GIT matured, I can imagine to drop the alsa-kernel repository and manage only one ALSA GIT tree. I only hope, that GIT is the final SCM system for Linux :-) (At least for several years.)
Ok, let's wait for 2.6.25 and then try to migrate.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On 07-02-08 12:27, Takashi Iwai wrote:
BTW, one big annoying thing is that developers have no complete kernel tree to access, and thus the patches that touch outside the ALSA subdirectory cannot be merged easily. People often send patches fixing together with OSS, etc, and I had to skip them. So, frankly, I'd love to have an access to the whole kernel tree. But, OTOH, this would make harder for other naive guys to give it a try because they need to download the big linux kernel tree git.
Maybe we can think reversely. Keep the kernel git tree as the primary development tree and generate the subset as the alsa-kernel package from the kernel tree automatically. In this way, you can avoid also sign-off messes, too.
This sounds good...
In this scheme, you don't have to stick with stgit. The normal git can handle patches well enough (via occasional rebase), and it's much much faster than stgit. Of course, stgit is still good for small number of patches, but it's not true for shared devel trees.
Rene.
On Thu, Feb 07, 2008 at 10:37:29AM +0100, Jaroslav Kysela wrote:
repository, I would like to consider a switch to GIT althought it means some changes in my scripts on ALSA server and my ksync tool.
Any objections?
No objections at all here - it'd really help us to have at least the kernel parts of the tree in git so we could work more directly with current ALSA.
Jaroslav Kysela wrote:
Hi,
it seems that GIT matured somewhat. git-push has been implemneted. It was main reason to not use GIT when we made decision between HG and GIT. As we could have potential problems with branches in HG repository, I would like to consider a switch to GIT althought it means some changes in my scripts on ALSA server and my ksync tool. I just successfully tried (a bit modified hg-to-git.py script) and it seems to be working properly. Any objections?
Jaroslav
I have no problem with moving to git. Just so long as we can still create alsa-driver packages from it. Will the git tree just be alsa-kernel, or will it be the entire linux kernel with the latest alsa additions?
James
On 07-02-08 10:37, Jaroslav Kysela wrote:
it seems that GIT matured somewhat. git-push has been implemneted. It was main reason to not use GIT when we made decision between HG and GIT. As we could have potential problems with branches in HG repository, I would like to consider a switch to GIT althought it means some changes in my scripts on ALSA server and my ksync tool. I just successfully tried (a bit modified hg-to-git.py script) and it seems to be working properly. Any objections?
Certainly none from me -- I'd much welcome a native git development environment.
Rene.
participants (11)
-
Andrew Paprocki -
Clemens Ladisch -
James Courtier-Dutton -
Jaroslav Kysela -
Mark Brown -
Pavel Hofman -
Rene Herman -
Takashi Iwai -
Timur Tabi -
Tobin Davis -
Trent Piepho