home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Talk
Bug/Crash submission system
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="and-81" data-source="post: 161482" data-attributes="member: 11844"><p>Hey guys,</p><p></p><p>As a developer on the project I thought I'd jump in and offer my perspective on this...</p><p></p><p>Generally, I must agree with infinityloop.</p><p></p><p>Just so everyone know's where I'm coming from:</p><p></p><p>I'm a professional software engineer, university trained. I've worked on software projects in the local arm of a fortune 500 company (read: big) and I have worked with bug-submission systems before.</p><p></p><p>I've worked on MediaPortal for some time now, and if you look through the forums you'll see that I've dealt with many users and many bugs in my plugins and other various coding. And my experience has been that talking with the user is more valuable that reading fault reports.</p><p></p><p>I'd swap one thousand auto-generated fault reports for one well written (by a person) fault report.</p><p></p><p>This project has thousands of users and only a handful of active developers, of which even less actively bug fix. In my personal experience (as a professional software engineer) I have found that when you give the end user a magic "submit fault report" button the quality of the "additional information" that is provided drops through the floor. That is to say, it's bad.</p><p></p><p>You end up with lots of useless fault reports. You still do get good ones, but you have to sift through the rubbish to find them. In my opinion, on a project like MediaPortal with a very high user-to-developer ratio that just wont work. If we had people who's job it was to fix faults, then it might work, but MediaPortal is no-one's <strong>job</strong>. It's a "spare-time" project, not a full-time job.</p><p></p><p>I know this is in contrast with krntea's experience. And I say it with full respect. Because it doesn't mean one of us is right and the other is wrong, it just means that on the projects we have worked on there have been differing situations in place that have lead us to different conclusions.</p><p></p><p>The important lesson here is that it's not clear cut that an automatic error log submission system would benefit the project. And it is my opinion that it would not.</p><p></p><p>However, I do believe that any extra information we could be given would be a benefit. Anything that would give us more details about what's happened will be of benefit. Just don't put a "Submit" button next to it, please! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite2" alt=";)" title="Wink ;)" loading="lazy" data-shortname=";)" /></p><p></p><p>I think the best way to do this might be to have a dialog pop up explaining that an error has occurred (you could turn this off in configuration) and give the user the chance to compile a "log collection file". For example, it could zip up all the relevant logs, and maybe even generate some additional ones.</p><p></p><p>The user would then be given instructions on how to submit the fault report. A link to the forums and the choice to proceed.</p><p></p><p>We've had a fair few bugs where the user's written feedback was far more important than the logs. Things like "Go to Music, then go to TV, and back to music ..." In a fault log, that just looks like random behaviour, but when the user spells out that those <strong>are the steps to produce the bug</strong> you have a lot more to go on.</p><p></p><p>And what happens when a new Release hit's the users, and there is a commonly reproduced bug in it. We'll get one hundred thousand emails in the first 3 days all saying the same thing. And one of those emails will be for a different bug, but will get lost in the mix. I really worry about flooding the developers with emails.</p><p></p><p>I could go on, but I wont, so just to summarise (cos I do ramble on):</p><p></p><p>1. I think an automated system for bug reporting is dangerous for this project.</p><p></p><p>2. But I do think more information for the developers is a good thing, so maybe a semi-automatic system would be worthwhile.</p><p></p><p>3. I am open to having my mind changed on this, but it would only be through seeing it in action on this project. Maybe we could trial it? Either way, it's going to take someone stepping up and coding it, and honestly that's probably going to take a new developer to jump in (krntea ?).</p><p></p><p>Anyway, it's all healthy discussion, just don't get too carried away believing it's some sort of panacea.</p><p></p><p>Cheers,</p></blockquote><p></p>
[QUOTE="and-81, post: 161482, member: 11844"] Hey guys, As a developer on the project I thought I'd jump in and offer my perspective on this... Generally, I must agree with infinityloop. Just so everyone know's where I'm coming from: I'm a professional software engineer, university trained. I've worked on software projects in the local arm of a fortune 500 company (read: big) and I have worked with bug-submission systems before. I've worked on MediaPortal for some time now, and if you look through the forums you'll see that I've dealt with many users and many bugs in my plugins and other various coding. And my experience has been that talking with the user is more valuable that reading fault reports. I'd swap one thousand auto-generated fault reports for one well written (by a person) fault report. This project has thousands of users and only a handful of active developers, of which even less actively bug fix. In my personal experience (as a professional software engineer) I have found that when you give the end user a magic "submit fault report" button the quality of the "additional information" that is provided drops through the floor. That is to say, it's bad. You end up with lots of useless fault reports. You still do get good ones, but you have to sift through the rubbish to find them. In my opinion, on a project like MediaPortal with a very high user-to-developer ratio that just wont work. If we had people who's job it was to fix faults, then it might work, but MediaPortal is no-one's [B]job[/B]. It's a "spare-time" project, not a full-time job. I know this is in contrast with krntea's experience. And I say it with full respect. Because it doesn't mean one of us is right and the other is wrong, it just means that on the projects we have worked on there have been differing situations in place that have lead us to different conclusions. The important lesson here is that it's not clear cut that an automatic error log submission system would benefit the project. And it is my opinion that it would not. However, I do believe that any extra information we could be given would be a benefit. Anything that would give us more details about what's happened will be of benefit. Just don't put a "Submit" button next to it, please! ;) I think the best way to do this might be to have a dialog pop up explaining that an error has occurred (you could turn this off in configuration) and give the user the chance to compile a "log collection file". For example, it could zip up all the relevant logs, and maybe even generate some additional ones. The user would then be given instructions on how to submit the fault report. A link to the forums and the choice to proceed. We've had a fair few bugs where the user's written feedback was far more important than the logs. Things like "Go to Music, then go to TV, and back to music ..." In a fault log, that just looks like random behaviour, but when the user spells out that those [b]are the steps to produce the bug[/b] you have a lot more to go on. And what happens when a new Release hit's the users, and there is a commonly reproduced bug in it. We'll get one hundred thousand emails in the first 3 days all saying the same thing. And one of those emails will be for a different bug, but will get lost in the mix. I really worry about flooding the developers with emails. I could go on, but I wont, so just to summarise (cos I do ramble on): 1. I think an automated system for bug reporting is dangerous for this project. 2. But I do think more information for the developers is a good thing, so maybe a semi-automatic system would be worthwhile. 3. I am open to having my mind changed on this, but it would only be through seeing it in action on this project. Maybe we could trial it? Either way, it's going to take someone stepping up and coding it, and honestly that's probably going to take a new developer to jump in (krntea ?). Anyway, it's all healthy discussion, just don't get too carried away believing it's some sort of panacea. Cheers, [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Talk
Bug/Crash submission system
Contact us
RSS
Top
Bottom
