El 01/12/08 05:36 Reinhard Tartler escribió: > (did you mail me in private on purpose? if not, feel free to quote > anything in this mail in public)
Oops, no, that was an accident. Replying to list now for completeness sake. > > Felipe Sateler <[EMAIL PROTECTED]> writes: > > El 30/11/08 15:07 Reinhard Tartler escribió: > >> >> > 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. > >> >> > >> >> Ugh. And why and when should we do that? > >> > > >> > For the same reasons you take a particular snapshot any time. It just > >> > saves you the hassle of manufacturing a tarball and importing it into > >> > a "fake" upstream branch. > >> > >> I cannot imagine any case when I would have wanted to do that. could you > >> perhaps name examples? Maybe I just don't understand this point, but it > >> doesn't seem too important to me either. > > > > Snapshots are useful when a bug has been fixed upstream, and the > > backporting is not trivial. Usually this would happen only when the > > bugfix is very invasive, involves license issues and/or upstream doesn't > > release frequently. > > These are all cases that don't happen that frequently, right? > > > In that case, all you would have to do is: > > > > git tag -s upstream/version $commit > > git checkout master > > git merge upstream/version > > # update changelog, patches, etc > > git-buildpackage > > > > git-buildpackage will find the tag by itself and create the .orig.tar.gz > > for you. > > Interesting. We should document this in some sort of tool knowledge base > on the team wiki pages. But not as first point but rather under the > "when things become tricky"-section. This can be done later on, when need arises. > > >> >> Would that make it rather difficult for upstream to know what changes > >> >> we have done in the package? > >> > > >> > I worded it badly. The tag would be present in the debian git > >> > repository, and as such it would be public. Also, upstream doesn't > >> > need to care about this, since we would still be using quilt patches > >> > that can be mailed to them. Also, if upstream is tracking the debian > >> > branch, merge points are stored, so upstream knows precisely which > >> > point in time you snapshotted. > >> > >> upstream would still have the hassle to understand git and the way we > >> use git. I'd prefer to save them this efford unless we have good reasons > >> to do so. > > > > Ehmm, that's what the quilt patches are for. If upstream wants to track > > debian, they can track the git repository. If they don't, you submit the > > quilt patches. Note that this workflow would only make much sense if > > upstream is already using git and you are tracking their master branch in > > your upstream branch. > > I was talking about the corner case you were sketching out > before. Upstream would have *additionally* have to know what *release* > we are using. and if we are using some "self-released" snapshot version > of upstream's VCS, upstream still would have to know what exact snapshot > we have used. Ideally this comes from the version number but that might > not work in some cases and upstream might want to verify that our idea > of the snapshot version matches upstream's. In principle this calls for > some ways to verify to "upstream" snapshot mechanism. This is > > a) trivial if know our workflow an are familiar to git > b) cumbersome if you don't use git. > > upstream's that don't use git fall into category b). We as team of > course fall in category a). > > I really don't want to make such a fuzz about it, we have already > stressed this point way too much. all I want to say is that upstream > snapshot taking is something we should rather avoid. If it becomes > necessary, we need to properly document and communicate how we are doing > it in a verifyable way to upstream. That's all. Indeed. Saludos, Felipe Sateler
signature.asc
Description: This is a digitally signed message part.
