HG vs GIT

HG vs GIT

[Jaroslav Kysela]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Andrew Paprocki]

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

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Jaroslav Kysela]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Trent Piepho]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Trent Piepho]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Jaroslav Kysela]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Jaroslav Kysela]

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.

Re: HG vs GIT

[Trent Piepho]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Mark Brown]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Mark Brown]

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.

Re: HG vs GIT

[Tobin Davis]

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.


-- 
Tobin Davis 

My opinions always matter :-)

	- Dan Malek on the linuxppc-embedded list

Re: HG vs GIT

[Tobin Davis]

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

Re: HG vs GIT

[Mark Brown]

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.

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Trent Piepho]

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.

Re: HG vs GIT

[Mark Brown]

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?

AK4114 - listing regs in proc - PATCH

[Pavel Hofman]

[-- Attachment #1: Type: text/plain, Size: 155 bytes --]

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>

[-- Attachment #2: patch-ak4114.diff --]
[-- Type: text/x-patch, Size: 1432 bytes --]

diff -r b0d97ac73e0f i2c/other/ak4114.c
--- a/i2c/other/ak4114.c	Fri Jan 25 15:24:50 2008 +0100
+++ b/i2c/other/ak4114.c	Sun Feb 10 21:06:38 2008 +0100
@@ -27,6 +27,7 @@
 #include <sound/pcm.h>
 #include <sound/ak4114.h>
 #include <sound/asoundef.h>
+#include <sound/info.h>
 
 MODULE_AUTHOR("Jaroslav Kysela <perex@perex.cz>");
 MODULE_DESCRIPTION("AK4114 IEC958 (S/PDIF) receiver by Asahi Kasei");
@@ -445,6 +446,26 @@ static struct snd_kcontrol_new snd_ak411
 	.private_value = (1<<31) | (4<<8) | AK4114_REG_RCS0,
 }
 };
+
+
+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;
+	int reg, val;
+	/* all ak4114 registers 0x00 - 0x1f */
+	for (reg = 0; reg < 0x20; reg++) {
+		val = reg_read(ak4114, reg);
+		snd_iprintf(buffer, "0x%02x = 0x%02x\n", reg, val);
+	}
+}
+
+static void snd_ak4114_proc_init(struct ak4114 *ak4114)
+{
+	struct snd_info_entry *entry;
+	if (!snd_card_proc_new(ak4114->card, "ak4114", &entry))
+		snd_info_set_text_ops(entry, ak4114, snd_ak4114_proc_regs_read);
+}
 
 int snd_ak4114_build(struct ak4114 *ak4114,
 		     struct snd_pcm_substream *ply_substream,
@@ -478,6 +499,7 @@ int snd_ak4114_build(struct ak4114 *ak41
 			return err;
 		ak4114->kctls[idx] = kctl;
 	}
+	snd_ak4114_proc_init(ak4114);
 	/* trigger workq */
 	schedule_delayed_work(&ak4114->work, HZ / 10);
 	return 0;

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: AK4114 - listing regs in proc - PATCH

[Takashi Iwai]

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

Re: HG vs GIT

[Timur Tabi]

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.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: HG vs GIT

[Takashi Iwai]

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

Re: HG vs GIT

[Jaroslav Kysela]

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.

Re: HG vs GIT

[Rene Herman]

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.

Re: HG vs GIT

[Mark Brown]

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.

Re: HG vs GIT

[James Courtier-Dutton]

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

Re: HG vs GIT

[Timur Tabi]

Jaroslav Kysela wrote:

> 	Any objections?

Not from here.  I think it's a great idea.  You might want to wait until after 
the 2.6.25 merge window is closed.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: HG vs GIT

[Clemens Ladisch]

Jaroslav Kysela wrote:
> 	Any objections?

No.


Regards,
Clemens

Re: HG vs GIT

[Rene Herman]

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.