[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 12:23:02 PM Thomas Goirand wrote:
> On 02/20/2013 06:20 AM, Barry Warsaw wrote:
> > * Figure out whether full-source or debian/ only works better (maybe give
> > us> 
> >   both repos so we can play with them and discuss the pros and cons from
> >   actual working examples).
> What is important, I believe, is that git-buildpackage always works.
> I've found that having a debian/rules entry called "get-vcs-source"
> which gets what is needed from upstream works quite nicely. Our
> workflow is described here:
> http://openstack.alioth.debian.org/
> The idea to use "git archive" was mostly from Julien Danjou. It's
> very nice because that way, we can use xz compression, instead
> of what upstream provides (that is, github .zip or .tar.gz, which
> isn't the best). It's also quite nice because that way, it's possible
> to tag a specific commit and package that as upstream release.
> This is mostly why I think using Git is convenient, so I really would
> like this to be part of the draft.
> Though this workflow only works if upstream uses Git, which isn't
> the case. In other cases, probably using a pristine tar branch
> would do.
> BTW, I of course agree that it's 100% necessary to make sure we
> have a unified policy, including on branch names and all. For branch
> names, I've used the following:
> - debian-sid
> - upstream-sid
> - debian-squeeze
> - upstream-squeeze
> - etc.
> But also:
> - debian/unstable
> - debian/experimental
> - master
> then I used the tags from the master branch.
> I think it's ok to have both naming shemes. The important bit,
> IMO, is that everything is referenced in the debian/gbp.conf so
> that nobody has to second-guess what to do.
> Just my 2 cents, and if help is needed for migrating, I hope to
> be able to be available if you ask.

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

Scott K

Reply to: