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

[andrew burke]

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


(Forgive the crude ascii, *'s denote submissions)


 stability fix \          / release 1 tag  / release 2 tag (0.17.1)
    /----------*----------|----------*-----|---------- .17 branch
   /           |                     \ critical bug fix
  /            | merged back to dev  | merged to dev
 /             v                     v
----*---*---*-**---*-*-*---**---*----*----*---*---*---*---- dev branch
          \                 ^        | critical fix
           \                | merge  | merge from .17 (not dev)
            \               |        v
             \--------------*--------*-----------|------------- .18 branch
 milestone feature completed/       release 1 tag/



Development
-----------
1) The dev branch is never guaranteed to be stable.
2) All major architectural changes, etc. take place in dev.

Releases
--------
1) Branch for each official release.
2) Use that branch to stabilize for that release.
3) Changes are always merged back toward dev from the outlying release
branches, never the other direction.
4) When the release is ready, tag the release branch.
5) Only critical patches that are going to be packaged up as an addendum
release are allowed in release branches after they have been tagged.
6) In general, release branches should only be getting stability/fixes.
7) Again, all changes flow back toward dev, not out from it.

Milestones
----------
Setting good milestones will help the project, both internally and in
relations with users.

For instance, if you have certain goals defined for .18, you can create a
branch for it almost immediately after you release .17.  The only changes
that should be taking place in the .18 branch are stability fixes and
features defined for that milestone.

People can then run the .18 branch with a lower chance of it being
unstable than, for instance, the dev branch.

If someone absolutely wants to be on the bleeding edge, they can run the
dev branch.

Granted, this may not be quite the solution you're looking for, but I
think this could actually end up helping you as myth becomes more popular:

- You are free to break the dev branch, because that's just the way it goes.
- 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.
- People who want to be on the edge, but not the bleeding edge, can have a
better experience working off the milestone branch.

------------

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.

If you guys are interested, let me know and I can go into greater detail
on any of the stuff above.

As myth becomes more widely used (and it will, it's a great piece of
software) you're going to have to deal with a greater demand for stability
and fixes.  I think applying some of the stuff above can help you guys
succeed.

andy