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: