> After reading the "should mythtv be forked?" thread I would like to > make a simple suggestion that IMHO would solve most of the [perceived] > problems with the stability of the CVS version of mythtv: A "stable" > tag could be added to the mythtv CVS tree and every monday morning a > cronjob would synchronize it with the HEAD revision. The developers
Although this is somewhat of a step in the right direction, it's really not the answer. This is what branches are for. Look, I do this stuff for a living. I work at a large video game company, and part of my responsibilities is to manage our various branches on different projects. There are ways that you can develop within this framework that both improve the user experience and untie the developers hands: 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. Why would it make sense for mythtv to use this model? It would make it easier for Isaac to find someone to manage each release, in that one person can own the given release branch. That person would be responsible for applying patches to that branch, generating point releases, etc. This should reduce the load on Isaac AND result in a better user experience, not to mention quicker response from someone on if your patch will make it in. If I were to help fork mythtv, it would be to implement a development model like this, and to implement some development policy with regard to bug/issue tracking, etc. I would love, instead, to see a development model like this adopted by the mythtv devs. And as I have offered before, I will offer again: I can help you make this kind of change. Yes, I think that subversion would be a better revision control system to implement this under, but at the least I could help people with some policy stuff to keep both users and devs moving happily along. 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. andy _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
