Felipe Sateler <[EMAIL PROTECTED]> writes: >> For point 1: How often do you "snapshot" upstream? Every upstream commit >> of their VCS or only upstream releases? What to do with upstreams that >> don't do commits in years? (think ffmpeg, toolame). > > In our case, we track upstream releases only, but only because it doesn't > make > much sense to do otherwise[1]: csound uses CVS (ugh), thus making it painful > to track it directly.
for cvs, there is cvs2svn, which can export in a format compatible to git-fast-import. Therefore AFAIUI it should be pretty easy to track the upstrem cvs with git. I'm not suggesting (yet) to do that. I think it only makes sense if we had a large set of patches that we want to get upstream. > In the case of ffmpeg, where there are no released tarballs, it would > make sense to directly track the git repository (ie, the upstream > branch is a clone of upstream's master branch). The particular problem with ffmpeg is that upstream uses svn externals to track the 'libswscale' subdirectory. The upstream git repository even leaves that directory out completely. I haven't found a better way to track upstream than what we currently have as the current get-orig-tar.sh, but I'm open for improvements on that. > In either case, "upstream" releases should be tagged (eg, > upstream/x.y.z~svn123 as git-buildpackage tags them). The debian diff > is not a diff against upstream's tip, but against these tags. If we track "upstream releases" (which I think we should do by default unless there are compelling reasons not to do so, see the ffmpeg example), indeed! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
