[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: