The hell of versions and SVN's (1 Viewer)

[tourettes]

Yes I know that no software is without bugs, but it must be much easyer to get the bugs sorted out if you are bugtracking to a fixed version, rather then a slippery slope between two versions. And it must be much easyer to NOT have to regard users in the pre-Alpha version of a new development. You can take on bigger issues and rewrite whole sections of the code, that the testers and and high-end users can start to debug, while the endusers is sleeping tightly in the old, but supported version.

MediaPortal 1.0 was in feature freeze (bug fix mode) over a year and to get rid of the all bugs would have taken another one at least. This is something that was considered to take too long. Maybe 1.0 should have been released as 0.9

Current architecture makes the bug fixing really slow and hard, thats why the MediaPortal II is in progress.

The fact is, that most endusers are forced to go with svn, for bug-fixes and for skin/plugin support that need "newer that SVN XXX version"

Forced or not. Only way to stop them to be forced is to disable the SVN build completely, but this wont help the MP itself.

I don't mind to have fewer and bigger-step versions, as long as I can get bugfixes to the present.
It's nothing remarkable about this. Everybody else do it this way, OpenSource or Pro.
Linuxvendors (like ubuntu)/Microsoft/firefox, you name it, they all do it.

So this is a question about what do we wan't to be. Just a hack for people that can read sourcecode and fix the bugs themselfs or a the free mediacenter of choice, like firefox among browsers.

I hope you understand that we are talking on completely two different projects. One is big, has huge developer base (even companies are paying for developers to write the code on Firefox side). Other one (MediaPortal) has only handful of developers, but the code base is almost equal on the size.

Only way how those 1.0 patches would be possible would be that so group from the users are willing to do two things

1) Start another SVN trunk where some skilled developer(s) are back porting the 1.0.x fixes. This is not an easy task as you simply cannot pick the wanted changes from other trunk and merge those and cross your fingers and hope that it works.

2) Create QA team that are testing the 1.0 patched trunk and make sure that the back ported fixes work and don't cause any new issues. (all 3rd party plugins would need testing as well as its easy to break plugin compatibility with MP)

So, any volunteers? Team doesn't have any resource for such... Of cource there is still that possibility that the 1.0 patched would contain even more severe bugs than the original 1.0 (smaller tester base, inexperienced developers on MP source code...)

 

[frenzy]

Personally I think that the workload that MP developers are putting out there is tremendous. And the community is an important part of the project. Yes there are bugs and yes there are different ways the team could go about but this is the reality of MP and this reality is one both the end-users and the testers have come to appreciate. Take for example the OP. He's never had a stable release and still he's here trying to make the project better by contributing with what he/she thinks is a good solution to what he/she thinks is a problem.

However, one should draw boundaries as to where his MP installation will go and what it will do. I've seen many people on the forums here trying to make MP work with skins and plugins that are either not supported any more or not working stably from the beginning. Others go through the installation skipping all the reading required and come to the forums for questions that could have been answered in the wiki. The first year I used MP -migrating from MythTV (mythdora 3.0)- I didn't change a thing in the basic installation and MP didn't crash once as far as I can remember. Sure I comprimised my viewing experience, sure I missed out on functionality (that WAS available) but I gained in stability. After the first year I installed a couple of plugins, which increased with time. I still use the blue3 skin as I know that I'm not ready to go to another adventure by changing skins and hoping their developers will keep them up to date.

Now about the SVN builds: Yes they fix the bugs, but some of them don't apply to everyone. More than half of the issues described in the changelog for 1.01 are such problems. And some of the rest would not be discovered by an end user. So if you're installing SVN build after SVN build then you're not an end user; you are a tester. And this is fine because you make the software better for the rest of us. But be self-conscious about it.

And to close, about the comparison of MP an open-source project to another open-source project, Firefox. Really, apples and oranges. The money that go into Firefox compared to MP is like comparing a glass of water to the Atlantic ocean. On the other hand take the Catalyst drivers. Lots of money, lots of experience, large user base but still ,

 

[poppabk]

I think in general the base of Mediaportal is fairly solid. I to went without features so as to have a stable system, sticking with 0.2.3.0 using blue 2 skin even as the SVN's and release candidates added functionality that I was really interested in. I am now on MP 1.0 and while it isn't 100% stable for me, I know that I am the cause of most of my issues - copying things over from the old install, not using b3 skin, multiple plugins etc. The added functionality comes at the cost of lower stability, but I am willign to accept this. My DVR from the cable company used to crash from time to time and that was dedicated hardware/software that provided purely DVR functionality so I don't feel I can really expect any better from MP.

 

[karlake]

Compromize

OK! It's maybe to much to ask of a small team, to maintain two sets of code.

We know that every new release, of any software, gives new bugs. First fixes for my ubuntu 8.10 came 1 or 2 days after the release. And they are a BIG team. So it's likely that 1.0.1 will give us new bugs to. That is life! So I still
feel that we need to do something for our endusers.
Is it possible to do it like this?

After a new release, the team concentrates on bugfixes only and release SVN's every week under the name of
eg. 1.0.1 SP1, SP2, SP3 and so on, until we have a solid platform. Then it changes name to 1.0.2.alpha with normal svn and the new development starts.

This is exactly the same amount of work for the team, only we state that official versions and SP's are for endusers and the versions to release skins/plugin to.

the newer versions with it's SVN's are for expert and people who like to be on bleading edge.

With this method, we will satisfy everybody's needs with exactly the same amount of work. Only differece is in the way we do it and that there are two different sets of download official, with SP and Alpha,Beta,RC with svn's

This will also focus the skin/plugin to be developed in the same way. They can stay in the official version for a long time and when RC1 of next version comes out, it's time to move on.

For the installer-idea to work in reality, it's important that all the plugin/skins in the bundle is made for the same version. Today some plugins/skins are made for official, some demand SVN X. Some other SVN Y. This new method could be a good way of making MP/skin/plugin to follow the same tempo.