On Wed, Sep 24, 2008, Gerfried Fuchs wrote: > But do they have decided because they thought about it, or followed by > repeating stuff?
You seem to be assuming that they didn't think about it. Clearly, that's not our case, and it's not a very nice thing to assume of your peers. Our choice is good enough and the simplest to implement. > 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. This is all subversion specific; if you care about checking "what SVN revision is this date-based snapshot using", then you are educated enough to look it up in the SVN manual, or to run svn info. > > > 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. :/ It's not an "interpretation", it's engineering and reproducible. And there is nothing user related here, users don't need to know which /SVN revision/ was used, if they need to check whether a feature is supported they can check with ffmpeg itself, which by the way also tells which revision was used... > > 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. So propose a patch to set the timezone before calling svn during get-orig-source? You're really making up problems here, the packagers knows what he is getting when he prepares the tarball. > > 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 help us set or provide or avoid TZ? Again, nothing ffmpeg specific here; check the archive, see how many dates are used. Do everybody a favor and do the discussion at the project or policy level. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
