Re: How does team maintenace of python module works?
On Wednesday, February 20, 2013 04:34:05 PM Thomas Goirand wrote:
> On 02/20/2013 12:41 PM, Scott Kitterman wrote:
> > This all seems to assume full source branches which is not something I'm
> > interested in participating in at all. I've tried it and I find it very
> > difficult to work with.
> >
> > Currently we have one VCS and one package layout. In the end, we should
> > have that still. Anything else raises a substantial barrier to
> > collaboration.
> >
> > Scott K
>
> Would you care explaining why full source branches is difficult to work
> with?
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.
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.
"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.
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.
Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to figure
out a workflow that integrates all those just seems impossible.
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.
Scott K
Reply to: