On Mon, 2006-12-18 at 09:25 -0800, Robert Hudson wrote:
> Hi Kristis,
>
> Thanks for the speedy integration. I'll E-mail you a private zip with
> my next set of updates based on what you have sent me. I'll try and
> address your comments as well.
>
> (1) I agree. I have now created a separate config file
> "TestDirector.conf" which is read in from within the TestDirector
> specific code, and it uses the bugtracker->{ installation_directory }
> for where this file resides (One of the problems is that Test Director
> will almost always exist on a different machine, so there is no default
> directory to store this). What I thought is that we could have the
I see. That's a good point. Both Bugzilla and Mantis suffer from the
same issue. They may be installed on a machine different than the one
the daemon is running.
> sample one stored in "etc/scmbug/" so there is a starting point for
> users.
>
> I think it is essential that we keep these values out of the Perl
> library files as every users system will need different values and I
> think it makes more sense for users to update a config file rather then
> the actual perl library files. (Also will make upgrade easier). I will
> try and get to some updated manual text to explain the config file.
Definitely. Go for it.
> (2) Yes, that is correct about the OLE Bug. Not sure about the version
> bit, not 100% sure what and when the version is checked. All Requests
> that get to TestDirectorUtils.pm go via TestDirector.pm which has the
> version check in it. Is this cover enough?
If you look at Bugzilla.pm, different SQL queries are issued for
different versions, due to schema changes. I was wondering if something
similar will need to happen in the future for Test Director. It will
probably become a problem when TestDirectoryUtils.pm needs to be
modified in the future.
Let's not worry about it yet.
> (3) Oops ... The following link should be just as good:
> http://bugs.activestate.com/show_bug.cgi?id=38968
Thanks.
> (4) Not an area I know anything about - sorry!
OK. We'll live with what we have.
> (5) Oops typo ... Corrected.
Thanks.
> I have made a first stab at the extra method for the merge, in principle
> it seems to be OK but there is one problem. Test Director stores all of
> the commit comments (and files changed) in one memo field (not separate
> rows in a DB like bugzilla). The code that I have added tries to pass
> all of that to the extract_affected_files() method but it only strips
> out the files from the last commit (And treats all the previous ones as
> comments). So this gives us two choices for this:
>
> (A) Update extract_affected_files() so that it can extract multiple
> sections out of the text passed to it.
> (B) Pre-parse the text to split the commits into separate transactions
> and pass them in separately to extract_affected_files().
>
> Obviously I prefer (A) :-) [Didn't know if other systems would hit the
> same problem] But didn't know if this was possible to do it there, what
> did you think?
Mmmm, I have trouble feeling strongly towards either. (A) has been
tested and known to work. If you could split them up using (B) and pass
them to (A), you'd have less of a chance to break things. (A) would
remain simpler logic, and (B) would be called (hopefully again as a
library function) only in systems needed. If it's possible, I'd rather
we broke up problems into smaller solutions.
But you may just implement (A) and see that the logic is not all that
more complex. I don't know.
Another guess I'm casually making is that if we implement (A) and a
comment is not parseable, we may have trouble continuing the parsing for
the remaining comments (and report more verbose error messages). While
with (B) we might retain that verbosity.
I don't know. Play with either ?
_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
