El 29/11/08 17:41 Reinhard Tartler escribió: > Felipe Sateler <fsateler@gmail.com> 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. There's also git-cvsimport, which I used for a while. However, the import stage is very slow, since it is done over the net. Subsequent updates are very slow too (unless one keeps the cvsimport updated very frequently). The problem is that one has to checkout every point in history, making it very slow for relatively large projects. > > > 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. Hmm, this is strange. I assume libswscale can't easily be built independently of ffmpeg, or that would be done, am I right? What motivation has upstream for doing this? > > > 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! Note that upstream releases need not be official. You can tag in your local copy some point in history as upstream/x.y.z+somedate, and use that as the upstream release. Saludos, Felipe Sateler
Attachment:
signature.asc
Description: This is a digitally signed message part.