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