* Loïc Minier <[EMAIL PROTECTED]> [2008-09-24 11:32:34 CEST]: > On Wed, Sep 24, 2008, Gerfried Fuchs wrote: > > Erm, google ratings never were a really good reasoning or argument for > > anything, they are just good for one thing: people like repeating stuff > > and often don't think about them. > > Uh this is not about random google ratings, it's about what your peers > have decided to do in their packages.
But do they have decided because they thought about it, or followed by repeating stuff? > > Like mentioned above, dates aren't unique. There were 7 commits done to > > the ffmpeg svn on that day, so it's not really clear which revision the > > date refers to ... > > The interpretation of dates by subversion is not to pick a random > commit in the day. It's not obvious to users trying to look for what version the checkout was. Maybe noting down in README.source how the specific dated checkout was produced would be helpful in that respect. > > So it was exactly the last commit from the day before that was used > > here? No commit from the day included? Furthermore, I wonder, wouldn't > > that approach have a timezone issue and maybe get you different > > revisions when being in different timezones? > > These are problems of interpretation of dates which are subversion's to > solve. Erm, so you rather like to push off the traceability requirements of where and how the upstream version was received to an "interpretation" of a tool rather to use proper informations that you actually have at your hands? Nice call, really userfriendly. :/ > Anyway, nothing specific to ffmpeg here; the only specific thing is > that we need to fix the documentation in copyright. ... and make sure with that that people in different timezones trying to get the same upstream source that you package won't fail with that approach. > I for one would become a standardized way to version our packages > coming out of various repositories. I understand why you think > revisions would make more sense to you, but I also like the human > readable nature of dates which tell me how old a snapshot is and allow > me to answer questions like "is this new upstream release more recent > or older than the snapshot in Debian?" without poking the upstream SVN, > or crawling the Debian changelog. The only thing here is that a date is ambigious with most VCSes when not also adding time (and timezone) informations to it, so it doesn't gain you too much. So long, Rhonda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
