Re: How does team maintenace of python module works?
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.
> > 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.
> > "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 (as I've
seen some people do who use Git) then any Debian changes to the upstream code
are difficult to parse and undocumented. When you have patches, they are
documented in debian/changelog and in the patch comments exactly why they are
there (I know sometimes this isn't done, but it is supposed to be).
> > Third, I have yet to see a workflow for maintaining debian/patches in a
> > VCS as part of a full source branch that was not more work than just
> > having the patches in a debian/patches and letting dpkg handle getting
> > them applied/ unapplied.
>
> Having full source branches do not prevent you from using debian/patches.
> I use that often, together with dpkg-source --commit and friends. If you
> have in debian/gbp.conf the following:
>
> [git-buildpackage]
> export-dir = ../build-area/
>
> patches are applied/unapplied by git-buildpackage automatically at build
> time,
> in a separate folder, which doesn't pollute your VCS tree. So I'd say
> it's the same,
> with the added benefit of being able to use upstream commits to generate
> diffs.
>
> > Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to
> > figure out a workflow that integrates all those just seems impossible.
>
> For all of them, you have bridges (cvs2git, git-svn, git-bzr-ng and
> hg-fast-export).
> If that doesn't work, you can use the pristine-tar thing, that should
> always work.
> I never used it, probably I should learn, it seems quite convenient. Can
> anyone
> give feedback about it?
I've had it explained to me how to do it, done it, and then the next time I
needed to do it could no longer remember it. For people that do packaging all
day, every day, I think many of these tools are great, but for people like me
for whom this is not the main focus of their day there's too much complexity
involved to be useful.
> By the way, I do the packaging of MLMMJ, and upstream provides both
> mercurial
> and Git, which I think is really awesome. If we could have that, and not
> only Git,
> that would be best, IMO, so that those who likes hg could use it. Last
> time I
> looked, it didn't seem so hard to setup. Probably that would be a nice
> addition
> to Alioth as well, so that any Alioth project using Mercurial would have
> Git too.
> Do you also think it would be worth asking the Fusion Forge team?
>
> > I've used partial (debian dir) VCS branches for years in both Debian and
> > Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at
> > all to full source.
>
> WIthout full source, how do you use git-buildpackage? Could you describe
> your workflow so that I can understand your view as well?
I don't. 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).
Scott K
Reply to: