[mythtv] development process

Daniel Kristjansson danielk at cuymedia.net
Tue Oct 3 01:07:52 UTC 2006

On Mon, 2006-10-02 at 20:04 -0400, D. Hugh Redelmeier wrote:
> Last week, I came across a previously observed bug in mythreplex,
> learned how to build Myth, isolated the bug, added the information to
> TRAC, and proposed a fix in the email list.
> My suggested fix has been ignored without comment.  Another fix has
> been adopted, so that is OK.  Except that I think that my fix is
> cleaner.
:-| Maybe it was missed? Who did you assign the ticket too?

> Without a test suite, it seems very likely that fixes could introduce
> new bugs.  Has any thought been given to adding a test suite?
Thought has been given, no one has gotten around to it yet.
I think part of the problem is that the most active MythTV
people are developers. We're used to Q&A departments that
do these things for us, and dealing with them tends to be the
least fun part of our job (outside meetings with marketing).

> PS: in my brief experience with Myth source, I've seen a number of
> small things that could be improved.  Not worth destablizing the
> programs, but stylistic improvements that I should have long-erm
> benefits in readability and maintainability.  Is there a consensus of
> "if it ain't broke don't fix it", or, alternatively, "lets polish this
> thing until it shines"?
Depends on the component. The plug-ins tend to need a lot of
work, so radical rewrites are more acceptable there. In core
functionality like say the video output classes we are more
conservative. For instance, I've created a branch where I'm
testing out video output changes. For a while we were doing
a complete rewrite of the DVB and EIT subsystems and we created
branches for that work that were merged back to head before
the 0.20 release (EIT is still a work in progress but that
work is going straight to svn head at the moment.)

It is highly recommended that any radical changes be discussed
on the dev mailing list first. Someone might already be working
on the problem, or the dev in charge of that component may
have some overarching plan that your changes would contradict.

We do insist on is that cosmetic changes, additional
doxygen documentation and functional changes each be done
in separate patches/changesets. And cosmetic changes are
usually not accepted unless they proceed some actual work
on the code in question (no need to generate phantom diffs,
unless it proceeds a major rewrite anyway).

-- Daniel

More information about the mythtv-dev mailing list