Alpha?? Seems more like a RC

Author: wktd 01 6th, 2009 in xn--9ou.com edit

First of all, I'd like to say thanks to the devs for all their hard work. XBMC is by far the best out there in media center software. I, like most got my first taste of it on an xbox and then started trying it out on linux not long after the source was available.

I've tried just about every htpc software out there for linux and have a lot of experience with all the linux media center contenders. I stopped using xbmc/linux about 6 months ago to try something new.. Mainly because I was getting really high cpu usage, and partly because I'm notorious for trying out new and different software.

Well, I had my fill of the other media center software I was trying and decided to see what progress had been made with xbmc because I was really missing it... To my surprise, the current state of xbmc/linux is quite polished... Looking at what has been accomplished and what remains to be worked on, I can see why it's not yet available for release. But for my purposes, playing music and movies from my nas, it's completely stable, functional and damn near perfect.

I did change to the xtv skin and added the Apple Movie Trailers script and both of those work perfectly. I've watched numerous movies without a hitch and my cpu usage is low, completely normal.

My hardware is not great, but fully capable of playing up to 720p content encoded x264. I'm running 1920x1080 resolution and the UI is beautiful. So in a nutshell, even though it's still in alpha stage, for my purposes it is completely stable, functional and worthy of release status.

What's the layout of this package? Like: comment configuration goto /etc, program itself goto /usr/bin, develop libraries? include heder files? userdata to $HOME/.xbmc? How about extra plugins? Fonts? and so on? Any plan? If we have all these defined, probably we can have a package for other Linux as well.

http://en.wikipedia.org/wiki/Development_stage
You can not name an alpha or a beta "RC", that is contradicting and would be confusing for those who understand the terminology (see the link above), and I agree with spiff that is is not a beta, ...normally you do a feature freeze during the beta stage (again, see the wikipedia article linked above) and we are not doing a feature freeze any time soon.

XBMC for Linux 2.1 alpha 1 (or "xbmc2.1-alpha1" as a package name) it will be :grin:

But nobody but developers should be compiling XBMC from scratch. If everybody rolls their own it becomes impossible to support. All endusers should be using official binary releases. It's your show, but I really think that's the wrong way to go.

just to make that point clear;

the day we store ANYTHING in the registry is the day i REALLY leave this project (i know, i've said it before and that failed miserably but that IS a show stopper).

and yes, definitely include the svn revision. even if in a somewhat discreet way

Windows configuration store in register table is just an example. But what's wrong with it? Isn't it Windows official way to save the configuration?

The deb will be made from 12195 which has been tagged as 2.1a1-candidate. You can checkout from:

https://xbmc.svn.sourceforge.net:/svnroot/xbmc/branches/2.1a1-candidate/

Use ~/.xbmc for user specific data is not only for multiple users' compatibility. I know many people use just one partition for everything, but also, some people using separate partition for different thing, and experts may mount /usr, /opt, /usr/local as read only unless they want to update packages. Or, /var cannot execute. And possible, /opt located in a small size partition.

I know this isn't a big issue for home user, but let's assume someday, some hacker want to hack Linux, readonly partition for important folders will be good. Another thing: maybe someday, XBMC decide to provide XBMC box, which require reliable, hack protected, ....

Anyway, follow Linux standard is good idea, I think. Of cause use soft symbol link to put them back to original layout is a good temporary solution.

Last I heard, they were looking to tag a version today.

we're looking for somebody with the knowledge to help us out so we dont have to use development time to read up on such things :)

Creating packages is not very difficult with debhelper; what are you looking for here? Prebuilt control and rules files, even though debhelper builds them for you?

Spoke to Spiff, the plan at the moment is to pop a twig off the linux branch and test it for a week or two then release xbmc-linux2.1-alpha1 to launchpad and then the ubuntu-universe repositories. AFAIK it will just be put in /opt for now-- this is alpha1, it doesn't need to polished to a fine sheen, it just needs to work for as many people as possible. The idea is to generate the same kind of publicity that OSXbmc has been getting.

You also have to keep in mind that XBMC is a cross-platform application, so the structure layout should preferably not differ too much between the different platforms, ...a XBMC for Linux developer/user should not be 'confused' by XBMC for Mac OS X file-structure, and vice versa.

Yes, agree. So, XBMC code base are same, but package will be different from OS to OS, right? And we are talking about packaging here. I would like to say: make it confiurable will be good. I saw we are now using "XBMC_HOME" environment variable. How about using $HOME environment variable to detect user specific data home directory? And abstract interface, so Windows system may get configuration from register table, and *nix can get from /etc and so on? Of cause, just my 2 cents.

OK, pull a twig off the branch then!

Then I suggest you or gamester or whoever make a sticky post designating that build as 2.1 beta1 RC1 and asking people to test it for a week or two; if it clears let me know and I'll package it up with proper dependencies, etc for the project owner to upload to launchpad.

Mozilla had multiple release candidates for each firefox 3 beta; it's not unheard-of. But sure whatever you guys want.

XBMC doesn't support that stuff, all the file locations are pretty much hard-mapped. Using ~/.xbmc for UserData would be particularly welcome. I guess we could use softlinks to put them in different directories but I had planned to just drop it in "/opt/XBMC".

such granularity is not in place as of yet atleast. can you pop by irc?

Do we want the SVN revision number stamped into the version number at this point? It's a little quicker to identify which version people are talking about and what fixes made it in, as we know users are going to report issues without reference to these kind of technicalities unless it's forced on them :)So maybe we could/would/should instead release alpha builds more often and therefore we need to give each alpha release the exact 5-didgit SVN-revision-number as the 'build' number?

So XBMC for Linux 2.1 alpha revision ##### (package-name "xbmc2.1-alpha-rev#####") where ##### is the SVN-revision-number

???

That would make it simpler to compare a apt-get package with someone who compile XBMC themselves.

Not 2.1 beta1 RC1 (as its alpha not beta and "RC" stands for Release Candidate which comes after beta)
http://en.wikipedia.org/wiki/Development_stage
It should be called XBMC for Linux 2.1 alpha 1 (at least I think so? ???)

OK. So the final name would be something like:

xbmc_2.1a1_svn12185-0ubuntu1_i386.deb

xbmc = package name
2.1a1_svn12185 = version_revision
0 = no root debian package
ubuntu = ubuntu package
1 = first ubuntu package released of this version
i386 = 32bit intel binary

I'd be happy to help out. Do you want to just publish today's daily as xbmc3.0b1 or would you rather pull a branch off the trunk and test it for awhile first?

I'm not opposed to having the SVN version as part of the version. For instance, ffmpeg release versions are of the form 3:0.cvs20070307-5ubuntu4, which to an end user makes no difference, they still only have to apt-get install ffmpeg. At the same time, a simple apt-cache show ffmpeg lists the necessary details. In the end, it saves the developers a lot of time and makes no difference to the end user.

Well if people say they're using v2.1a1 we know exactly what commit that is because we released it. Also the changelog.txt will be included in the package since it's pulled from SVN and the plan is to package up the SVN pull with no changes. So it would list the latest commit numbers in there as well.

IMO endusers shouldn't have to hear or deal with commit numbers at all. Their involvement should end at "sudo apt-get install xbmc". They installed v2.1a1, that's all they should need to know.

...I can see why it's not yet available for release....

...in a nutshell, even though it's still in alpha stage, for my purposes it is completely stable, functional and worthy of release status.We want to have a PPA (Personal Package Archive, an apt-get Debian package compatible with Ubuntu) (https://launchpad.net/ubuntu/+ppas) ready before we change the status of XBMC for Linux to "Alpha", and ther simple reason that it is no such PPA package yet is that our developers have not yet have time do begun work on it, ...only thing we done so far is registered a project for XBMC on launchpad.net
https://launchpad.net/xbmc

Patches are welcomed to speed up this process
http://xbmc.org/wiki/?title=HOW-TO_submit_a_patch

Well the idea was that it was the first release candidate for the first beta; if we found problems with that build and had to test another one it would be 2.1b1rc2. Or 2.1a1rc2 if you prefer.

IMO calling it beta is better than alpha even though it's not fully feature complete as more endusers are willing to try betas than alphas and the base functionality does work pretty damn well.

I guess my point is that while we know exactly what we released for a few weeks, after that we have to refer back to SVN to check exactly when fixes went in in relation to the tagged release. I guess I'm coming from 4+ years of near weekly xbox releases, where no revision number, and at best having a date are the only things to go on, which often isn't enough to quickly evaluate and reply to a user as to whether it's fixed, or is something that needs addressing etc. Under *nix one presumes we won't be having such a rapid release cycle anyway, so the point is possibly moot.

I personally don't see the difference between v2.1a1 and v2.1.12345 alpha 1, but I'm a mathematician ;)

Cheers,
Jonathan

Windows configuration store in register table is just an example. But what's wrong with it? Isn't it Windows official way to save the configuration?

Most applications in win saves in %appdata% (Bring up run and type that and you'll be there).
Linux usually have it in ~/.(something)
And OSX have something alike this.

So what I'm saying is that the only sane thing is to have the UserData folder exaclty the same on all O/S so it's switchable, not care for registry or OS specific things. Most crossplattform apps do this (ie Firefox)
Were that folder reside is trivial code change as Spiff pointed out. But mixing in registry nonono :)

I think that mixing the rev. number seems like a good thing, it's a nice reference when trying to help people out. Easier than just a log

i'd suggest the latter, to make sure there's no show stoppers around.

also, please dont refer to it as trunk - might confuse users. trunk is the xbox build:)

finally, version will be 2.1

Basic functionality is there and working pretty great, but the interface is still unpolished with overlapping entries in system info, still refers to the xbox in multiple spots, still has listings for game saves, the main menu programs entry is entirely useless, several options for video lock up the program, etc. It's definitely not release candidate quality but it could be packaged up and released as beta.

And ideally the SVN revision should be displayed on the sysinfo screen. Not sure if there's a way to include it automatically in the source via SVN trickery or whether it has to be scripted prior to build?

using ~/.xbmc for a profile is trivial, needs a code change, sure, but its just changing one location

To me as a developer, v2.1a1 or whatever is completely meaningless. I'd have to actually lookup in SVN what that means. To a user it's meaningful - that's the version they grabbed, and the version they expect to be able to report bugs about and get support on. If we had an army of support personnel this wouldn't be an issue, but when I am supporting users directly I need to know what it is I'm supporting, and revision number gives me exactly what I want, immediately. It's just one less impediment to me offering support.

It seems to me the simplest solution is to simply dump the SVN revision number in the release version number. This has the additional bonus that if and when nightlies are packaged up it keeps versioning the same across the board.

Cheers,
Jonathan

Which svn version is being targeted for deb construction? I'd like to start the AppleTV development and begin identifying issues to be solved and it would be helpful to start on a similar basis.

Thanks
Scott

Well if we want to map out various locations for files to unix standards, I guess now is the time to do it. Like /usr/bin/xbmc for the executable, /usr/share/xbmc for skins and icon resources and such, /usr/lib for libraries, /etc/xbmc for system-wide settings, ~/.xbmc for user specific data, and so on.

Alternatively, we can just drop the sucker in /opt/XBMC. Using ~/.xbmc for user-specific UserData would be particularly nice for upgrades and such. Not so much for multiple users' compatibility as I don't really see multiuser XBMC catching on anytime soon and we have profiles for that anyway.

FYI the OSXBMC structure is already quite different, Gamester.

Well you guys never marked any releases since 2.0.1, instead various groups of people compiled their own branded SVN pulls with various addon skins and scripts and put them up every so often. Since xbmc for linux is 100% legal you have the opportunity to exert more control.

... and I really hope the windows devs don't use the registry. Gahh.

it's definitely still alpha. it will reach beta once ALL features from the xbox (relevant) are done.
this includes a functional programs for instance

#If you have any other info about this subject , Please add it free.#

My rights and duties- employer asks me to provide testimony in its civil lawsuit TU Settlement - Credit Inqury on my credit report

Alpha?? Seems more like a RC

Category

Recent Posts

Archives

Blogroll