[mythtv-users] Status of 0.25

[Michael T. Dean]

On 02/20/2012 03:27 PM, Angela Schmid wrote:
>> And, in fact, RCs have been used for many versions:
>>
>> MythTV .24 Release Candidate 2 Now Available!
>> http://www.mythtv.org/news/142/MythTV%20.24%20Release%20Candidate%202%20Now%20Available!
>>
>> MythTV .24 Release Candidate 1 Now Available!
>> http://www.mythtv.org/news/141/MythTV%20.24%20Release%20Candidate%201%20Now%20Available!

Where RC1 was Oct 18 and 0.24 release was Nov 11 ( 
http://www.mythtv.org/news/143/MythTV%200.24%20Available ), which is 3 
1/2 weeks.

>> 0.23 Release Candidate 3 Available
>> http://www.mythtv.org/news/137/0.23%20Release%20Candidate%203%20Available
>>
>> 0.23 Release Candidate 2 Available
>> http://www.mythtv.org/news/135/0.23%20Release%20Candidate%202%20Available
>>
>> 0.23 Release Candidate 1 Available
>> http://www.mythtv.org/news/134/0.23%20Release%20Candidate%201%20Available

Where RC1 was Mar 24 and 0.23 release was May 10 ( 
http://www.mythtv.org/news/138/MythTV%200.23%20Available ), which is 6 
1/2 weeks.

>> 0.22 Release Candidate Available
>> http://www.mythtv.org/news/130/0.22%20Release%20Candidate%20Available

Where RC was Oct 14 and 0.22 release was Nov 6 ( 
http://www.mythtv.org/news/132/MythTV%200.22%20Available ), which is 
just over 3 weeks.

Oh, and somehow I missed 0.22 release candidate 2, at 
http://www.mythtv.org/news/131/MythTV%200.22%20Release%20Candidate%202%20available

> I have never seen the RC Releases on the main page, because the RC1, RC2 and the Release itself were announced within 2 weeks ! So
> to see the RCs you had to go to the homepage every week.

Or you had to read the MythTV mailing lists at least once in a 
while--something you /should/ be doing if you plan to run 
unstable/development code of any kind (or, IMHO, if you plan to run 
MythTV in general).

http://www.gossamer-threads.com/lists/engine?list=mythtv&do=search_results&search_forum=all&search_string=release+candidate+available&search_type=AND&search_fields=sb&search_time=&search_user_username=&sb=score&mh=25

We also post announcements to the list.  I just didn't feel like looking 
up all those links, too.

> I wanted to make a point, that at the actual releases many problems arised and most people wait for the fixes release.
> The testing phase with RCs should be longer.
>
>> I will include the original announcement here....
>> On Wed, 2012-01-25 at 20:28 +0000, Mark Kendall wrote:
>> Feature Freeze: 12th Feb
>> 0.25 Beta        : 4th March
>> 0.25 RC1        : 18th March
>> 0.25 Release   : 2nd April
> Now it is 4 weeks, I will live with that.

Note that 4 weeks is likely to be 2 or more release candidates, so it's 
likely to be almost exactly like before.

>   A release schedule on the homepage would be great.
>
> Maybe someone can reply on my other question:
> Are there well-know commit-tags (tags) working well for television and video ?

Working well is subjective--since you use different parts of MythTV than 
I and since you almost definitely use different settings than I (which, 
BTW, is the real reason MythTV can't be fully tested--because it allows 
configuring too many things too many ways, often because it's easier to 
throw in a setting than to make MythTV just do the right thing).

Anyone using unstable/development MythTV code of any kind needs to 
follow -commits and -dev lists and make their own decision whether to 
risk their own recordings/stability/usability for the purpose of helping 
to test the code.  Also, ideally, people will commit to working to 
resolve the issues and/or identify the specific problem completely so 
that it could be fixed.

Then again, if you all want longer testing of RCs, we could--instead of 
stopping development work for 6 weeks to do a release--stop development 
work for 12 weeks or 6 months or ???  (In other words, a release cycle 
seriously affects our ability to do what we need to do to make MythTV 
better--and I don't just mean new features, but also refactoring of code 
to fix what we currently have (since that's almost always too invasive 
to do during a feature freeze, even if it's not a new feature and is 
fixing existing bugs).)

Mike