[mythtv] What can packagers/distro developers do to help thestability of 'released' version of MythTV?

[Isaac Richards]

On Wednesday 23 February 2005 06:16 pm, andrew burke wrote:
> > This would help avoid problems like today's change that was known to
> > break modules - people who track "mostlystable" wouldn't get that code
> > until the change is finished.  If the developers consider a new feature
> > to be ready for further testing, just update the tag to point to that
> > release.
>
> Subversion might be a better solution than CVS in that it allows easier
> branching/tagging, etc.  Not to mention that it's just plain nicer to work
> in from a developer standpoint.
>
> Branching could conceivably solve all these issues if a little bit of
> policy is put in place:

It still takes time, which I don't really have.  I can't work on code _and_ 
deal with merging stuff between lots of branches, or testing multiple 
branches.

> - You are free to break the dev branch, because that's just the way it
> goes.

I have a better policy. =)  CVS HEAD simply doesn't get broken for any length 
of time.  That said, I am planning a branch for the mythui conversion, if I 
can't manage to get it to transition cleanly.  We did the same (made a 
branch) with the scheduler rewrite, until that was stable.

I use CVS in production (ie, it's what's running in my home theater, recording 
the shows I want to watch), and I update it at least once a week.  If it 
breaks, I miss a show.  It's good incentive to keep everything stable, 
instead of doing a flurry of testing after development's "finished" for a 
given release.

> - Users are getting releases with critical bug fixes more 
> often/quickly because you don't have to worry about tons of other changes
> in the release branches.

The main time sink in dealing with a release is dealing with all the different 
packages - I'm planning on consolidating most/all the plugins into one module 
in CVS + one download, which should help considerably with things there.  I 
don't really spend much time worrying about tons of other changes. =)

The main reason 0.17 took so long was because I wanted to get the DVB code 
integrated and (mostly) stable.  I'm hoping to shorten the time between 
releases in the future.  I want to do 0.18 mid-next month, mainly due to the 
database pool that avalanche is in process of committing (fixes random 
stability problems for a number of people).

> - People who want to be on the edge, but not the bleeding edge, can have a
> better experience working off the milestone branch.

Right - that's really how I treat cvs head.

> I would be willing to help you convert from cvs to subversion, possibly
> even offering to host the tree on a colo'd box.  I'd also be willing to
> set up trac (http://www.edgewall.com/trac/) to help you manage tickets,
> milestones and view the repository.

I've got pretty good hosting, but thanks for the offer.

Isaac