Nightlies and the noob

@Gnits wrote:

1) how do install a nightly when i already have a nightly installed (does it change every night (assuming you are coding at the time)

If windows or mac, just reinstall over the top. If ipkg based, you can add the firefly repository to your ipkg repositories and do “ipkg update; ipkg install mt-daapd”.

There are instruction on adding firefly to the nslu ipkg repo list on the nslu2 install guide on http://wiki.fireflymediaserver.org

As far as the frequency of updates, it depends on what’s going on. When I’m working on large changes, I generally work in a branch outside of the trunk. I don’t often commit changes, just when I want to work on a machine other than my laptop, so I’ll commit broken code to just get to the same point on another machine.

Right now, for example, I’m redoing all the file and socket handling, so rather than using an emulation layer on windows, I’ll be using native CreateFile calls etc. Hopefully that will either fix some of the windows wierdness, or give better error messages.

Also will let me get 64-bit file support, and hopefully a single place to add file munging for non-utf8 file systems. Hopefull will fix a bunch of long-standing bugs. But it’s a pretty huge effort, and I’m mostly coding off-trunk in the “ron-ssl” branch. (I started out adding ssl, and realized that I would need to fix the socket and file handling to add ssl support).

You can see where I am (when I do commit) at http://trac.fireflymediaserver.org, under timeline. That shows the blow-by-blow of feature commits.

2) do you keep some running commentary about the fun (changes) you are having with the nightlies so we can also enjoy them?

As fizze mentioned, I do keep commentary at http://nightlies.mt-daapd.org.

3) do you maintain more than one dev stream? IE, one with general changes and improvements you are trying out, and one that is far more experimental?

Only as necessary. Generally I don’t. Usually I just post a warning that some nightly is likely to be unstable, and there are a bunch of people that will go ahead and try it anyway. I use their feedback to converge back to stability, and so forth.

4) how often does the nightly become the stable build? Do you try to do that on some sort of a schedule?

Right now, there *are* no stable builds. The last stable release (0.2.4) is *really* old. I want to fix playlists, refactor the db, and make that an official stable release. Once I really do get a stable release, I want to start releasing stable builds more often. Now that I have a build system in place, it’s a lot easier to release stable builds.

So once I get something I’m mostly happy with, code-wise, I’ll work toward a stable. I keep hoping it’s only a month or so away, but it’s been a month or so away for a couple years now. :/

— Ron

@kellyharding wrote:

Incidently I’ve got mt-daapd running perfectly (svn-1586) on Debian ‘Unstable’ (Debian ‘Lenny/Sid’?).

Perhaps I should add a sid target for nightlies, that way I could easily turn that into a stable when debian releases a new stable…