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

[Manish R. J. <man...@gm...>]

On 2/9/06, rdm...@bi... <rdm...@bi...> wrote:
>
> 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=3Dctime, last_update=3Dmtime, and date_uploaded=3Datime.
>
> >> 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 fairl=
y
> >> 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 th=
e
> > code is still working, it wd be better to do all the changes followed b=
y
> > 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.)


Ok gr8. Go ahead.

> 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.


Thanks David. Fabio, I'd like you to take up one of the functionalities, an=
d
complete that. For now, photo resizing is the topmost priority.

--David
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Flickrfs-users mailing list
> Fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flickrfs-users
>



--
http://tuxmann.blogspot.com

"If I have seen further it is by standing on the shoulders of Giants"
"Software is like sex: it's better when it's free."
"An infinite number of monkeys typing into GNU emacs would never make a goo=
d
program."