Re: How does team maintenace of python module works?
Thomas Goirand <zigo@debian.org> wrote:
>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.
I don't keep local copies of things I don't work on regularly, so for team packages I would be downloading all 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.
Right. Someday there may be a source format git, but until then ...
>>>> "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.
I've done the boring bits enough that my fingers mostly do them without much attention from my brain. If I were going to abandon my current approach, I'd have to see significant advantages for a new way and I don't.
Scott K
Reply to: