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

[Allan Stirling]

John Barbershop wrote:
> Stuart Auchterlonie stuarta at squashedfrog.net wrote:
> Please stop saying 'for some reason'. 
<snip>
> ...is that for some reason in some cases the channel scanner reuses cached 
> data from the database. 
Your use of 'for some reason' is better than a developer 
with a significant amount of code in Myth... Because?


> 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 
Really? Is that what happened? Trac history says something 
different:

06/03/09 11:13 -
You add a comment to a fairly unrelated ticket.
http://svn.mythtv.org/trac/ticket/2053

06/03/09 11:13 -
You open a new ticket.
http://svn.mythtv.org/trac/ticket/6600

06/03/09 12:06 -
I lock the original ticket. Note - This is not closing it - 
It just prevents the discussion from continuing on that 
ticket. As has been discussed a number of times, discussion 
of known bugs that adds no useful information should happen 
on IRC, mailing lists, etc. 2053 is already a ticket 
assigned to Daniel.

I then close your new ticket, since it really does contain 
no new information. I mark it as a duplicate of 2053.

4 weeks later, you comment on:
http://svn.mythtv.org/trac/ticket/6638
This ticket was raised by Daniel, who has submitted another 
large chunk of Myth code. It's what's usually marked as a 
task ticket. You will again note that this ticket was 
locked, since these sorts of discussions (as evidenced in 
this mail thread) tend to go on and on with no actual 
communication happening. It is not closed, it will be worked 
on when someone has time.

> 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.

No. You don't need to submit a patch for people to be 
interested in helping you. You just need to not rub people 
up the wrong way at your first encounter. Commenting on 
multiple tickets with no additional information is just trac 
spam.

> going to fix it (closing tickets with one-line comments).
... At which point, take it to email, as the one-line 
comment says.

> You seem to primarily view end-user bug-report 
> tickets as 'wasting your time'
Good tickets? Not at all. Noise tickets opened sequentially 
just to raise the perceived visibility of an issue? Sure.

> 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 
<snip>
> 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.
> 
Strangely enough, I am involved in Q&A / Issue Management. 
Both in my day job and here on Myth. Feel free to see where 
my contribution to Myth is - It's exactly in getting rid of 
tickets like you submitted.

We have 541 open tickets. A good proportion of these tickets 
haven't even been triaged in 6 months. Leaving tickets open 
with no possibility of resolution would not be a good thing 
- It gives the perception that the issue may be worked on. 
To be honest, about 30% of the tickets in Trac should be 
closed - mainly because trunk has changed so much since they 
were opened. However, good bug reports with definitive logs 
etc will remain open.

Sure - I may be quick off the trigger to close / pass back 
tickets. But there is _no one else_ stepping up to do the 
triage work. The moment someone else does that, my workload 
drops and I can maybe think about looking more in-depth to 
your (essentially) undocumented issues.

One of the things that makes this particular issue difficult 
is that you have no way to go back to the point in time 
where you saw the problem. So we can't ask you for logs. We 
can't replicate the issue on our systems.

Your continued assertion that it's a caching issue is 
incorrect. I personally can think of no mechanism by which 
old data would be used until mythfilldatabase was run. This 
is obviously true of the other developers that have 
commented on this issue.

To be frank, your continued abrasive attitude does not 
really motivate anyone to dig into your issue. Sorry to be 
blunt here, but we are all volunteers.

Oh - Threats to fork only work if you have developers. If we 
had enough of those for a realistic attempt to fork, we 
would not be having this discussion, since there would be 
enough people to actually maintain Trac. The same obviously 
applies to a fork - You need a certain number of people to 
maintain a codebase this large.

There are less then 10 active, committing developers. For a 
successful fork, you will need at least that number, 
probably 20 since the codebase is really not linear and is 
very interdependent.

Cheers,

Allan.