[News] MediaPortal 1 Development - get involved! (2 Viewers)

[infinite.loop]

Please use this thread if you have questions regarding the MediaPortal 1 Development - get involved! news.

 

[FrankDrebin]

I highly recommend that everybody gets involved in getting us a https://forum.team-mediaportal.com/area-51-testing-area-552/native-blu-ray-support-102375/. That would be a cool feature to have!

 

[Edalex]

When you click New posts -> English forums only you can't see new topics from new subforum. Is it ok?

 

[tourettes]

I highly recommend that everybody gets involved in getting us a https://forum.team-mediaportal.com/general-development-no-feature-request-here-48/native-blu-ray-support-102375/#post808004. That would be a cool feature to have!

That thread is now moved to Area 51 sub forum. Hopefully it will draw more interested people to take part in the testing.

 

[messo001]

I am sorry, but this sounds like a terrible idea:

1) It is highly likely that a new feature/bug submission will interfere with contributions by other developers. So testing an installer for changes from just a single developer does not seems like a good idea.

2) If people have the time to test every single installer a developer publishes (and I presume there would be lots of those floating around once this comes out), then they are most likely developers themselves. Hence, this makes this whole thing kinda redundant.

I think you guys should implement a system that is known to work. Have a look at any random open source project that is highly successful, e.g. Firefox. There are a handful of branches that testers can play with and provide direct feedback. This makes development much more manageable and feedback more meaningful.

 

[Koen Zomers]

I like the sound of this! I have tried to get "involved" before, but I really had no clue where to start. Also due to my limited spare time available I like the sound of just picking up small pieces and not right-a-way having to get involved in the whole structure. Can somebody provide me a pointer where to start?

 

[technick]

Hi, it's a good idea to make tests more serious but I see only full install and in my case I don't want made a full update to test something, it should be nice to have (also) only modified files based on a specific version.

 

[Oxan]

I am sorry, but this sounds like a terrible idea:

1) It is highly likely that a new feature/bug submission will interfere with contributions by other developers. So testing an installer for changes from just a single developer does not seems like a good idea.

2) If people have the time to test every single installer a developer publishes (and I presume there would be lots of those floating around once this comes out), then they are most likely developers themselves. Hence, this makes this whole thing kinda redundant.

I think you guys should implement a system that is known to work. Have a look at any random open source project that is highly successful, e.g. Firefox. There are a handful of branches that testers can play with and provide direct feedback. This makes development much more manageable and feedback more meaningful.

(Disclaimer: I'm not a developer of MediaPortal itself, but I think they share my ideas).

1) Not really. In big software like MediaPortal there are many different areas where things can change which don't interfere with each other. For example the SQLite rewrite and the native blu-ray support have nothing to do with each other at all (just picking two examples from the forum). Of course changes in the same component might cause problems, but that's only a tiny fraction of the changes.

2) It's not about having everybody testing all installers. It's about people testing a feature they want to have. If 100 people test only two installers, that's not worse than having 2 people test 100 installers (I think it's even better). Also, developers like to have things easy too. I'm a developer myself but with published installers the chance I'll test one of them is a lot higher then when I've to build it myself from source.

3) I don't think testing integrated branches is better. It makes tracing back errors to the source a lot harder.
Also, I don't think Firefox is the best example: it's quite strictly managed by Mozilla, which have way more manpower then MP has.

 

[Paranoid Delusion]

I am sorry, but this sounds like a terrible idea:

1) It is highly likely that a new feature/bug submission will interfere with contributions by other developers. So testing an installer for changes from just a single developer does not seems like a good idea.

2) If people have the time to test every single installer a developer publishes (and I presume there would be lots of those floating around once this comes out), then they are most likely developers themselves. Hence, this makes this whole thing kinda redundant.

I think you guys should implement a system that is known to work. Have a look at any random open source project that is highly successful, e.g. Firefox. There are a handful of branches that testers can play with and provide direct feedback. This makes development much more manageable and feedback more meaningful.

Remember this is for people who want to help, and have means to setup and test outside of a production machine, no one wants to screw up a working MP install that a user relies on.

More people testing something, the higher likely hood of coming across a scenario where a fault shows up.

This is voluntary, not compulsory

 

[Bleazle]

...Remember this is for people who want to help, and have means to setup and test outside of a production machine, no one wants to screw up a working MP install that a user relies on.

More people testing something, the higher likely hood of coming across a scenario where a fault shows up.

This is voluntary, not compulsory

I agree with all of that PLUS I think it will be good to be able to "watch" what is being worked on and how it's shaping up, even if I don't actually test the releases As PD said the more people that test something the more likely it is that issues will be found -> fixed = a more stable release version. This is a great idea imho.