Re: How does team maintenace of python module works?
On 02/20/2013 11:45 PM, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
>> On 02/20/2013 10:43 PM, Scott Kitterman wrote:
>>> First, full source repositories are much larger than debian only
>>> repositories. I don't have a full checkout of all team packages locally,
>>> so that means if I'm going to touch a package I don't have to download,
>>> it's more time, bandwidth, etc. Even for a new upstream version, debian
>>> directory in the repository and upstream tarball is still smaller.
>> If you are modifying some packages, it's to upload them at some point.
>> In such case, you will need the upstream tarball, right? I don't see where
>> the waste of bandwidth is then.
> A VCS with all the upstream history will always be bigger than the tarball for
> just the current release. Sometimes substantially so.
But you only very rarely clone from scratch, and only get some
incremental changes.
While with tarballs, you always have to get the full of it.
>
>>> Second, I think Debian packaging work and upstream's product should be
>>> distinct in the source package. The source package is what Debian as a
>>> project ships as the source for DFSG purposes and it should be useful.
>> Which is why we have branches. One with the upstream code, and one
>> with the debian folder added. Everything being contained in that debian
>> folder. So it's really distinct.
> You're missing my point. If it's only in the VCS, it's not in the source
> package. The source package needs to stand alone without the VCS to, in my
> opinion, properly comply with the spirit of the DFSG.
It's funny that you say it this way. I've read some other opinion saying
that with the
tarball, you're missing lots of information from upstream. That person
went up to
say that he thought it'd be a good idea to package the git repository as
source
package (sorry, I can't remember who and when, just that it was in
-devel@l.d.o).
I quite agree with this view.
>>> "Here's a huge mass of code and to understand what we did to it, you need
>>> to refer to this external repository (VCS)" is not socially acceptable to
>>> me.
>> It's not any different to have absolutely zero upstream code in the VCS:
>> you will need to refer to an upstream tarball, which has "a huge mass
>> of code".
> Right, but if you embed Debian specific changes and don't use patches
That's not what I do.
> I know sometimes this isn't done, but it is supposed to be
I agree it's a bad idea, so we are on the same line.
> I generally unpack the upstream tarball, export the debian dir from
> the VCS into the unpacked tarball, update the package, build it with dpkg-
> buildpackage, and then commit the changes back to the VCS repository with
> debcommit (which is very nice since it speaks to multiple VCS through the same
> interface).
So, basically, you're doing all by hand... That's very tedious. IMO, the
whole
point of using git (or any other VCS), is to use either git-buildpackage, or
"git-stuff" (that's a package name...), so you have tools to do all this
manual
boring work. git-stuff works the opposite way. You'd do all the changes in
your packaging, then it would write the debian/changelog based on the
commit messages. I find it a lot better, because then you can have a history
of you changes, do rebase, squashes, cancel, etc. without the risk to loose
any of your changes.
Thomas
Reply to: