On 02/20/2013 04:57 PM, Matthias Klose wrote: > So there would be no way anymore to build using upstream tarballs?
Upstream tarballs, in some cases, is a concept of the past. When they are released (sometimes, they simply don't exist), it may only an image based on a git tag. Then using Git tags is often better, because tags may be PGP signed. I live in China, and the Chinese government did twice some man in the middle attack... Tarballs don't include PGP signatures. Plus it's possible for me to tag at any point in time, any commit, and use that to generate a tarball. Signed git tags is the new trend, you shouldn't fear it, and stick to the old 1980's concepts forever, only because we always did this way. If sticking to our old habits is not the only valid point, that there are real technical reasons why we should never be using a git tag as the key for an upstream release, or if you think they might be real difference between the "git archive" generated xz file and the github/gitorious/etc. tag based tar.gz, please explain. > This doesn't sound appropriate to force on a whole team. Of course it's not. In fact, I don't think it's the right thing to do to impose rules set that strong, and write them into a stone. There's no "one size fit all", and such a rigidity may bring inconvenience. I by the way think that switching everything from SVN to Git will probably be painful for a lot of the team members, which is why I think it isn't a so good idea, and that best would have been to allow both even if I understand why using more than one VCS might be at least annoying and probably very inconvenient sometimes. This doesn't mean that we shouldn't try to define some standards, and try to stick with them whenever possible, but only to some reasonable extend. Also, if you have valid arguments to use one type of workflow, and if it really is convenient to work the way you tell, I will happily adopt your way. Please share your view, and packaging habits and tricks! My intention when describing our workflow was to give ideas, and confront them. If everyone shares, I'm sure this will be beneficial. > I don't think that many of the people that voted are aware of your implicit > changes (no release tarballs, including upstream source in the VCS) by moving > to > git. > > Matthias Once more, I never wanted to change anything in the team, I just wanted to be allowed to use Git when relevant. I voted CDBA, in this order, as I didn't wish to distrub anyone that likes SVN. Now, do you know if it is possible to use git-buildpackage without storing the full upstream source in a branch? I never did that way. For me, using git-buildpackage is mandatory, it is simply too convenient. What is the problem of storing upstream source code anyway (that's the 2nd time I ask, as nobody explained yet why it's a problem)? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5124da42.9020...@debian.org