[mythtv] Why MythTV didn't handle the UK Freeview lineup change

[John Barberio]

Stuart Auchterlonie stuarta at squashedfrog.net wrote:
> You may know different, but we spoke to a guy working for Arqiva/BBC  
> who said
> this is not the case. According to him, the rules state that if a  
> channel
> changes it's service id should too and when this has failed to  
> happen in the
> past it's been the source of some friction between engineers and  
> broadcasters.
>
> Virgin may understandably not have wanted their channels to go off- 
> air on many
> STBs because of a change in serviceid, keeping it in place meant  
> they could
> inform viewers of the need to rescan. They skirted the rules.
>

Here's the problem. You have the opinion of an engineer at Arquiva  
about what best practice is, and that engineers don't like what  
broadcasters do, and that this was skirting around the rules. The  
problem is, that in the end the change did go out that way, so was  
obviously ultimately approved for transmission.

> Now clearly we need to be updating channel names & numbers which  
> hasn't always
> worked in the past for some reason, but it's being worked on. It's  
> not our job
> to keep you informed, if you just spent some time reading the -dev  
> list, -
> commit list, wiki or existing tickets you might have noticed that  
> the channel
> scanner is being completely re-written for 0.22.

Please stop saying 'for some reason'. A work around and suggested fix  
has been offered. The specific problem that made scanning fail to work  
is that for some reason in some cases the channel scanner reuses  
cached data from the database. If you use mythfilldatabase to manually  
sync up the database before the channel scan, channels are properly  
deleted. So to prevent channels being resurrected, you need to sync  
the database before a channel scan. This might not fix the underlying  
problem, but it makes the rescan work, which is all I've been asking  
for.

End of discussion on the bug it's self, the rest of this mail is about  
the tricky problems of how to handle Quality Assurance and Issue  
Management in open source software projects.

> The reason you have received scant attention before now is because,  
> whether
> you intended it or not, you have come across as aggressive and rude.  
> Many
> stated 'facts' in your original posts were simply wrong and you made  
> great
> used of hyperbole. You were telling us how serious a problem was and  
> how we
> should be reacting. The way you phrased things is what we regularly  
> see from
> people who think they are entitled to attention and support - we  
> have no time
> or respect for such individuals. I hope that this is simply a  
> misunderstanding
> and that you did not intend to come across in this way.
>

I only started using 'hyperbole' as you call it when you closed the  
bug report with the cryptic "Trac is not a discussion forum." and  
marking it as a duplicate, without saying what it was a duplicate of!  
I had to struggle to get you to answer that you would only respond to  
this on the developer's mailing list. And when you did, your first  
response was to dismiss it by saying it was 'obviously' caused by  
reception problems, which was very obviously not so since other  
channels on the same mux worked, and information was getting there but  
assigned by mythtv to the wrong channel. You've said little to make me  
feel confident you made any investigation into the problem when you  
closed the first ticket.

> Most other users understand that we do not work for them, they wait  
> patiently
> for issues to be addressed. If they cannot wait they fix the problem
> themselves and provide patches, which is certain to show/earn more  
> respect and
> is what the OSS community is all about. This goes for everyone here  
> - if you
> want attention and quick fixes then go buy WinMCE where your money  
> will pay
> for it.


This is in fact one of the major fallacies of open source software.  
Most people not part of a large software project don't have time to  
learn the programming tools and system design used, even if they are  
programmers. Demanding that people 'earn your respect' by coding on  
your project before you'll listen to their bug reports is one sure  
fire way to stop getting bug reports, and probably frightening people  
off from even trying to learn what's needed to join in.

And this wasn't a matter of waiting. Every indication you made, was  
that the bug didn't exist ("caused by poor reception"), or that you  
weren't going to fix it (closing tickets with one-line comments). You  
managed this particular issue by being confrontational from the  
outset, making strange and incorrect assumptions about the bug, and  
being exceptionally poor in communication. You seem to primarily view  
end-user bug-report tickets as 'wasting your time', and seem actively  
hostile to non-programmers.

I assume you're a very good programmer, but that skill doesn't  
transfer over into Q&A and issue management. No one is forcing you to  
do the Q&A/Issue Management side of the project if you don't like  
spending a lot of time talking to end users, and working out what bug  
reports are saying. Q&A/Issue Management is not like the programming  
side, when you take ownership of a ticket you have to focus on it,  
make sure you seriously understand the ticket or have made a best  
effort to, and keep the end user who filed that ticket as fully  
informed as they need to be. It's a lot harder for someone to take  
over a ticket from you, especially if your actions have frightened off  
the user. If talking things over with an end user who is not a  
programmer is not your best suit, then it's something someone else  
should handle. If you're not comfortable with this side of Q&A/Issue  
Managment, then the most you should do is read over tickets is to  
review them to see if you can spot where in the code the issue is, and  
respond if you've found it.

Ideally only people who are prepared to handle it like they're in a  
customer services department should really be taking on ownership of  
end-user filed bugs. If the project doesn't have any of those people,  
perhaps you need some non-programmers on board to handle your issue  
management and end-user support?

You might want to look into why Debian ended up switching from Glibc  
to Eglibc, because of repeated incidents of one very good programmer  
being very bad at end-user issue management.

   - John