[mythtv] 'stable' tag proposal

[Jay R. Ashworth]

On Mon, Mar 21, 2005 at 06:48:24PM -0500, andrew burke wrote:
> 1) Always branch for releases.
> 2) Always merge changes back into the 'dev' branch, never from dev out.
> 
> Why does this work?
> 
> When you make a release, let's say 0.17, you create an 0.17 branch.  When
> a critical bug is found in that branch, it is fixed *in that branch*, a
> new release is generated (0.17.1) and the fix is merged back to the dev
> branch as appropriate.
> 
> Why is this better?
> 
> Because the user gets timely fixes without jumping through lots of hoops
> (getting CVS, building, etc.).  The devs are also totally free to do
> whatever they like in the dev branch, there is no requirement that it be
> at all stable.
> 
> You can also do things like: branch for 0.18 well before you intend to
> release 0.18.  The only checkins then allowed on that branch are for
> stability/bugfixing.  This allows a grace period to really firm up that
> branch before putting it out in front of users.  Again, any changes made
> in this branch are merged back to the dev branch as necessary.

Not a bad idea.

Not a justification for your other outlook, but still not a bad idea.

> I think the general attitude of 'screw the users' that is easily perceived
> on this list has turned a lot of people off.  I am suggesting that it's
> time that the mythtv devs decide: is mythtv just for the elite or is it
> for the average user?  If you decide the former to be the case, then a
> fork probably makes sense.  If the latter, then it seems that some changes
> should at the least be considered to how mythtv development currently
> happens.

I'm not a developer in any sense, so I can say this:

Screw the users.  They're getting a *lot* of *really sweet* code FOR
FREE.  They didn't have to pay Isaac or, in general, anyone else, *any
money* for what they got.  And they were made aware that the code is
prerelease -- if in no other fashion, by the version number.

There's an etiquette for situations like this, andrew, and you're not
helping by encouraging those who fail to apply it.  If you're not happy
with the development model, then go ahead and fork the damn thing.  

But get lost from pissing off the guy who's *cutting code* that the
rest of us are happy to invest a little time getting running, willya?

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

      If you can read this... thank a system adminstrator.  Or two.  --me