Icecast - Mar 2005 - rfc: bring ices-kh60 into mainline asap

hi everyone!


currently, karl's branch of ices has a number of interesting features 
that the ices release does not:

* jack support (very important for a number of users i know, and 
generally cool in terms of interoperability)

* really nice metadata updates and on-the-fly savefile changes

* runner threads for load distribution on smp boxen

* on-the-fly switching of input sources (useful for recorded material 
during pauses in the live programme)

...

the first time i used ices-kh was about a year ago,  and even then it 
has performed very reliably, for over a week in 24/7 operation.
at the time, it relied on a hacked version of libshout, so it was clear 
that it could not easily be merged into the main ices branch without 
major disturbances.

since libshout-2.1 is out, however, it does not require a modified 
version any longer.

a number of ices users (especially those who do live streaming, myself 
included) have been pestering karl to merge his changes, so that even 
casual users can profit from the improvements.[1]

so far, this has not happened, since some of the changes in the -kh 
branch are fundamental.
to speed up the merging, and since there are no regressions in 
functionality when moving from ices-2.0.1 to ices-kh60, why can't we 
just push ices-kh60 out as ices-2.1rc ?

it has been tested by a number of people, and getting the latest 
improvements from mainline into karl's tree might easier than the other 
way round...
from a release manager's pov, this might be questionable, but given the 
many alternative stream sources, ices is not a critical single point of 
failure in the xiph infrastructure, and changes in ices do not affect 
any other xiph products.

i hope i'm not stepping on anyone's toes, and i'd really like to
hear
what the ices maintainer has to say about this.

all i can say is, there are many people who really need the features in 
-kh, and it would be beneficial if they became as visible and easily 
available as possible.


keep up the great work!


best regards,


j?rn


[1]
as a side note, the whole development process under the xiph umbrella 
can be very hard to follow for outsiders - in addition to the sheer 
volume of the sources, they are also rather scattered over the svn tree. 
the -kh branch is almost invisible on the net, unless you know exactly 
what you are googling for. i don't blame anyone for this, but it is 
another argument for a quick merge.

On Wed, Mar 02, 2005 at 09:55:28PM +0100, Joern Nettingsmeier
wrote:
> the first time i used ices-kh was about a year ago,  and even then it 
> has performed very reliably, for over a week in 24/7 operation.
I heartily concur; I've had Karl's version running 24/7 since last
summer, and aside from one incident in October (where it and icecast
argued over whether it was already broadcasting or not), it's been
running smoothly all the time.  And that's over a connection spanning
13-14 hops across the continent, with the usual stream of network
failures (which brought ices2 2.0 to its knees).
> to speed up the merging, and since there are no regressions in 
> functionality when moving from ices-2.0.1 to ices-kh60, why can't we 
> just push ices-kh60 out as ices-2.1rc ?
Last time I checked, there were changes in the XML syntax which, small
as they were, required slightly rewriting the configuration file.  Is
this no longer the case?  I think most users would expect a minor
version number to be a drop-in replacement.
> as a side note, the whole development process under the xiph umbrella 
> can be very hard to follow for outsiders - in addition to the sheer 
I'll admit it took me a while to figure out that changes in 2.0-kh were
not included in 2.1...


-- 
             Fr?d?ric Bri?re    <*>    fbriere@fbriere.net

 =>  <fbriere@abacom.com> IS NO MORE: 
<http://www.abacomsucks.com>  <=