ALSA release cycle

ALSA release cycle

[David Henningsson]

Hi,

At Plumber's we discussed the ALSA release cycle. Our releases recently 
have been irregular, and the reasoning behind why a release was done at 
that time, has not been very obvious.

IIRC, we kind of leaned towards releasing every six months. I don't 
remember if there was any consensus about whether to try to align this 
cycle to something else (e g Gnome, KDE, Fedora, Ubuntu, etc), or not.

We also said that we should discuss this on the mailinglist as the ALSA 
release manager (Jaroslav Kysela) was not present during Plumber's. So 
this effectively is a mail to kick off that discussion. Any opinions?

Also, as a side note (or perhaps proof of the problem!), it seems ALSA 
1.0.26 was just released without even a notification on this mailinglist...?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: ALSA release cycle

[Daniel Mack]

On 07.09.2012 13:38, David Henningsson wrote:
> Hi,
> 
> At Plumber's we discussed the ALSA release cycle. Our releases recently 
> have been irregular, and the reasoning behind why a release was done at 
> that time, has not been very obvious.
> 
> IIRC, we kind of leaned towards releasing every six months. I don't 
> remember if there was any consensus about whether to try to align this 
> cycle to something else (e g Gnome, KDE, Fedora, Ubuntu, etc), or not.

... or the kernel? At least for the kernel parts of ALSA, syncing an
ALSA version to kernel version would automatically tell us which patches
will make it into a new release. Plus, it would also be easier to
compare feature sets (something like "ALSA 1.0.26 gives us what we have
in kernel 3.6").

Would that be feasible or am I missing something?


Daniel

Re: ALSA release cycle

[David Henningsson]

On 09/07/2012 01:58 PM, Daniel Mack wrote:
> On 07.09.2012 13:38, David Henningsson wrote:
>> Hi,
>>
>> At Plumber's we discussed the ALSA release cycle. Our releases recently
>> have been irregular, and the reasoning behind why a release was done at
>> that time, has not been very obvious.
>>
>> IIRC, we kind of leaned towards releasing every six months. I don't
>> remember if there was any consensus about whether to try to align this
>> cycle to something else (e g Gnome, KDE, Fedora, Ubuntu, etc), or not.
>
> ... or the kernel? At least for the kernel parts of ALSA, syncing an
> ALSA version to kernel version would automatically tell us which patches
> will make it into a new release. Plus, it would also be easier to
> compare feature sets (something like "ALSA 1.0.26 gives us what we have
> in kernel 3.6").
>
> Would that be feasible or am I missing something?

I took that up as an alternative. I think more people leaned towards six 
month cycles, but it's still an open question.

To me, I also think aligning releases to the kernel makes sense, but 
it'll also mean a lot of releases with little change in, so maybe six 
month cycles are better for that reason.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: ALSA release cycle

[Takashi Iwai]

At Fri, 07 Sep 2012 14:51:10 +0200,
David Henningsson wrote:
> 
> On 09/07/2012 01:58 PM, Daniel Mack wrote:
> > On 07.09.2012 13:38, David Henningsson wrote:
> >> Hi,
> >>
> >> At Plumber's we discussed the ALSA release cycle. Our releases recently
> >> have been irregular, and the reasoning behind why a release was done at
> >> that time, has not been very obvious.
> >>
> >> IIRC, we kind of leaned towards releasing every six months. I don't
> >> remember if there was any consensus about whether to try to align this
> >> cycle to something else (e g Gnome, KDE, Fedora, Ubuntu, etc), or not.
> >
> > ... or the kernel? At least for the kernel parts of ALSA, syncing an
> > ALSA version to kernel version would automatically tell us which patches
> > will make it into a new release. Plus, it would also be easier to
> > compare feature sets (something like "ALSA 1.0.26 gives us what we have
> > in kernel 3.6").
> >
> > Would that be feasible or am I missing something?
> 
> I took that up as an alternative. I think more people leaned towards six 
> month cycles, but it's still an open question.
> 
> To me, I also think aligning releases to the kernel makes sense, but 
> it'll also mean a lot of releases with little change in, so maybe six 
> month cycles are better for that reason.

Well, releasing alsa-driver package for each kernel release makes some
sense.  People can use it like compat-wireless stuff.  In that way,
distros can provide the update module package even on distro kernels
from a released tarball.

For the rest, we don't have to bind the release version among all
components any longer.  The things became already stable, and we've
seen already version skips in packages like alsa-oss.


Takashi

Re: ALSA release cycle

[Daniel Mack]

On 07.09.2012 14:51, David Henningsson wrote:
> On 09/07/2012 01:58 PM, Daniel Mack wrote:
>> On 07.09.2012 13:38, David Henningsson wrote:
>>> Hi,
>>>
>>> At Plumber's we discussed the ALSA release cycle. Our releases recently
>>> have been irregular, and the reasoning behind why a release was done at
>>> that time, has not been very obvious.
>>>
>>> IIRC, we kind of leaned towards releasing every six months. I don't
>>> remember if there was any consensus about whether to try to align this
>>> cycle to something else (e g Gnome, KDE, Fedora, Ubuntu, etc), or not.
>>
>> ... or the kernel? At least for the kernel parts of ALSA, syncing an
>> ALSA version to kernel version would automatically tell us which patches
>> will make it into a new release. Plus, it would also be easier to
>> compare feature sets (something like "ALSA 1.0.26 gives us what we have
>> in kernel 3.6").
>>
>> Would that be feasible or am I missing something?
> 
> I took that up as an alternative. I think more people leaned towards six 
> month cycles, but it's still an open question.
> 
> To me, I also think aligning releases to the kernel makes sense, but 
> it'll also mean a lot of releases with little change in, so maybe six 
> month cycles are better for that reason.

Which would correspond to every 2nd kernel release then. Plus, in case
we would ever want stable branches of the ALSA kernel code base, the
work for picking the appropriate patches is also already done for us.

Such a correlation would really help to picture what version of drivers
people are on when they write about issues they have with a specific
ALSA version.


Daniel

Re: ALSA release cycle

[Jaroslav Kysela]

Date 7.9.2012 13:38, David Henningsson wrote:
> Hi,
> 
> At Plumber's we discussed the ALSA release cycle. Our releases recently 
> have been irregular, and the reasoning behind why a release was done at 
> that time, has not been very obvious.

It is not. I depends mostly on my free time to do so.

> IIRC, we kind of leaned towards releasing every six months. I don't 
> remember if there was any consensus about whether to try to align this 
> cycle to something else (e g Gnome, KDE, Fedora, Ubuntu, etc), or not.

I would prefer to keep the releases on demand. If you look to the 25->26
user space changes, there are just few of them. Now, when the API will
be enhanced, I will do more releases.

For the driver stuff, we can talk what's best to do. The correlation
with the kernel releases are mostly only by the release date, but the
driver repositories contains the latest code (which is more related to
the linux-next tree than the stable linux trees). The alsa-lib tries to
be compatible with all previous code using the kernel<->user space API
versioning, so there is no potential problem in this area.

Because the most of changes are in the drivers now, I'm thinking to do
more driver releases (probably using the fourth version number) between
the standard releases of all packages. But I'm not sure if it's worth to
do these releases, because the tar-balls with the actual code for all
packages are available immediately
(http://www.alsa-project.org/snapshot/). Users have a way to get the
latest code. I see only issues with the kernel interface changes - it
may make the driver code non-compilable on older kernels. Actually, I'm
trying to create a self-testing framework which will be triggered after
each repo commit and it will notify developers to the alsa-devel list
that the alsa-driver repository is broken for some kernels.

> We also said that we should discuss this on the mailinglist as the ALSA 
> release manager (Jaroslav Kysela) was not present during Plumber's. So 
> this effectively is a mail to kick off that discussion. Any opinions?
> 
> Also, as a side note (or perhaps proof of the problem!), it seems ALSA 
> 1.0.26 was just released without even a notification on this mailinglist...?

I'm sorry, I was testing the packages in the Fedora build system. I
found some issues with the alsa-tools package (missing header files for
hdajackretast in the tar-ball) yesterday and I was able to finish my
tests today. I postponed the e-mail notification for this reason.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.