[MPlayer-DOCS] [PATCH] How to do regression testing using CVS

[The Wanderer]

On 11/26/2005 06:46 PM, Guillaume POIRIER wrote:

> Hi,
> 
> On 11/26/05, The Wanderer <inverseparadox at comcast.net> wrote:
> 
>> On 11/26/2005 04:08 PM, Guillaume POIRIER wrote:

>>> +If you have lot of hard disk free space (a full compile currently takes
>>> +100 Mb), copy the oldest known working version before updating it, it will
>>> +save time if you need to go back.
>> 
>> "it; this will save time".
>> 
>> Personally I keep two separate Wine trees, one for "tracking
>> current CVS" and one for peforming regression tests; it's just
>> easier that way. Not that I've had occasion to do many Wine
>> regression tests so far, it's just that I created one for the first
>> regression test and haven't bothered to delete it.
> 
> I did not want to get into further details in advising do do the
> binary search in a separate tree. I figure the user either never used
> cvs and has no tree or has already a tree and will think about
> backuping it if needed. If the doc is too verbose, ppl tend to skim
> trough it.

Acknowledged. You didn't apply all of the other suggestion, though - you
changed the comma to a semicolon, but not "it" to "this".

>> It would be a good idea to make sure that the "100 Mb" number is
>> correct for MPlayer before committing this - actually I think it's
>> incorrect; a quick 'du -hs' on my primary, fully-compiled copy of
>> main/ gives me 309MB. While we're at it, are we using the "Mb"/"MB"
>> distinction or not?
> 
> My tree is 103Mb but it's compiled without debug symbols, and without
> all supported features of MPlayer. I guess this figure varies from
> ppl to ppl. It's probably safer to say 300MB (which is the standard
> figure for a MPlayer source tree compiled with debug symbols).

Indeed. My own MPlayer tree also includes every feature I could manage
to get to compile, except for the GUI and a few pieces of hardware
support I couldn't use anyway; I'd guesstimate that a true "includes
absolutely every feature possible" compile would come in somewhere in
the 300-350 megabyte range.

I note that you didn't actually change the number, despite this comment.

>>> +<screen>
>>> +cvs update -PAd -D "2004-08-23 15:17:25 CDT"
>>> +</screen>
>>> +This will allow you to find easily the exact patch that did it.
>>
>> "to easily find", if not a more extensive rephrasing.
>> 
>> Since I've snipped the other place where this appears: do we really
>> want to specify the examples in Central Daylight Time? I believe
>> that the reason Wine does so is because that's where their CVS
>> server is located, and so that's the time zone for which their CVS
>> log will be synchronized; since our server isn't located in the
>> same time zone, we may want to use a different TLA. (Using none is
>> not advisable, for reasons I'm not entirely clear on.)
> 
> I've checked: the zone indicated is "-00" so it either means GMT, or
> "local". In any case, I don't think it matters that much, so I
> removed it

It may in fact matter; I don't recall details, but I believe that I had
difficulty with not being able to get the expected results out of an
update until I also specified the time zone. (I was looking at the Wine
CVS log archive and saw a patch committed at a specific time, but
updating to a minute or two before that and then trying to update to a
few minutes later showed no change to that file.) I don't know exactly
what was happening internally, but I believe it did make a difference
for me.

>>> +If you find the patch that is the cause of the problem, you have almost won;
>>> +report about it to
>>> +<ulink url="http://bugzilla.mplayerhq.hu/">MPlayer Bugzilla</ulink> or
>> 
>> "the MPlayer Bugzilla" (the definite article doesn't necessarily
>> have to be part of the link name)

No comment on this - did you miss it, or just not snip it?

>>> +subscribe to
>>> +<ulink url="http://mplayerhq.hu/mailman/listinfo/mplayer-users">MPlayer-users</ulink>
>>> +and post it there.
>>> +There is a chance that the author will jump in to suggest a fix; or there
>>> +is always the possibility to look hard at the patch until it is coerced to
>>> +reveal where is the bug :-).
>> 
>> There is something grammatically wrong with this last sentence
>> (after the semicolon, since it's really a separate sentence there
>> despite the ungrammatical "or"), but I'm not quite sure how to fix
>> it without introducing other problems.
> 
> I came up with smth different. Please tell me if it's okay.

See below.

> +cvs update -PAd -D "2004-08-23"
> +</screen>
> +The date format is YYYY-MM-DD HH:MM:SS.
> +Using the CDT date format ensure that you will be able to extract patches
> +in a way that will be compatible with the
> +<ulink url="http://mplayerhq.hu/pipermail/mplayer-cvslog/">MPlayer-cvslog archive</ulink>.

If you're going to remove the "CDT" entry in the date, you need to also
remove this last sentence. As I've said, I myself am not necessarily
sanguine about removing it, but if the one does go the other needs to go
as well.

> +If any non-programmer reads this, the fastest method to get at the point
> +where the problem occurred is to use a binary search, that is &ndash;
> +search the date of the breackage by repeatedly dividing the search
> +interval in half.

You're sure that that's an emdash, not an endash? The former appears as
something like " -- ", the latter as something like "-"; the former is
used to separate words, the latter to join them or to split a single
word into parts.

Also, and this is my own fault for not being clear, you've put the dash
in the wrong place. I meant that it should replace the comma after
"binary search", not that it should go in before "search the date".
Sorry about that.

> +If you have lot of hard disk free space (a full compile currently takes
> +100 Mb), copy the oldest known working version before updating it; it will
> +save time if you need to go back.

As noted above, the number has not been changed. Also, you didn't
address the question of whether we use "MB" or "Mb" (or even make any
distinction between them).

> +There is a chance that the author will jump in to suggest a fix.
> +You may also look hard at the patch until it is coerced to reveal where
> +the bug is :-).

Better; not perfect, but better. (I don't think you want to sit here
jumping through hoops until I'm satisfied that we've reached perfection;
if I decide that it's that important, I can work over things myself
after commit.)

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.