Re: How does team maintenace of python module works?
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
Reply to: