Re: [Flickrfs-users] Bug fixes and my enhancement checked in.

[<rdm...@bi...>]

On Thu, 9 Feb 2006 at 10:03, Manish Rai Jain wrote:
> On 2/9/06, rdm...@bi... <rdm...@bi...> wrote:
> Gr8 that you finished off the ctime/mtime functionality. And I think it wd
> be more useful if ctime is 'time photo is taken' extracted from photos Exif
> data. While utime wd be the time when photo is uploaded.

If by 'utime' you mean what is in the code self.atime, then yes I
agree that makes maximum use of the available data.  So
date_taken=ctime, last_update=mtime, and date_uploaded=atime.

>> If it's OK with you, Manish, I'd next like to do something that I
>> actually enjoy, though many programmers don't: refactoring.  I can see
>> several places where the code could be tightened up and simplified,
>> now that you've roughed out how it all works.  It will mean some fairly
>> radical changes to the code, but in the end I think it will be easier
>> to maintain and enhance (or I wouldn't suggest I do it!).
>
> Ok David. No probs with me, but I got some concerns. Lot of changes may tend
> to break the code. To make sure that the changes can be tracked, and the
> code is still working, it wd be better to do all the changes followed by
> thorough testing locally, and then put it upstream in 1 go, instead of doing
> cvs update after each small change.

The way I do this is I have a test suite.  I only check in code when the
test suite passes.  The only problem is that my test suite doesn't
test 100% of the functionality.  In particular I'm not currently testing
upload.  So I guess I'd better figure out a way to do that.  Come to
think of it I had ideas about that when I first started writing the tests
but had to give up because of some of the bugs I've now fixed, which
means I should be able to resurrect that test code...

Anyway, the way I'd like to do this is to make incremental changes,
checking in as often as I can, where "I can" is defined as the full
test suite runs without error.  Does that address your concerns?
(That methodology, by the way, is what I followed in doing the bug fixes,
although in that case I was making more and more of the tests pass with
each commit.  But I always made sure nothing new broke before I did
a check-in.)

> Also, there are some functionalities and testing I wanted to complete:

How about if I throw this list into a 'TODO' file in CVS?  Presently
I'll take a look at tackling them.

--David