[Piuparts-devel] piuparts team development / documentation upload
john at movingsucks.org
Sun Feb 25 03:03:35 CET 2007
On Sat, Feb 24, 2007 at 05:49:36PM +0100, Holger Levsen wrote:
> I'd like to push the team development process of piuparts some bits further
> now :) We have an alioth project set up, but currently it's only used for
> this mailinglist, and then svn is empty.
> We briefly discussed the SCM to use on #debian-qa and to use svn, which is
> already set up on alioth for us. So I just created the usual trunk, branches,
> tags and people directories and committed that.
> And then I went ahead and committed the version currently in etch+unstable
> (0.20-3) _including_ the debian directory to trunk - I hope someone else can
> enlighten me and us how to use svn-buildpackage to build a non-native package
> from it :) (Otherwise I'll come up with some other hack to achieve the same.)
> svn co svn+ssh://svn.debian.org/svn/piuparts
After reading documentation and a little experimentation, it seems the
way to use svn-buildpackage is the following:
1. Keep upstream tarballs in /tarballs (e.g.
2. Keep just the debian/ directory in /trunk
3. Set the "mergeWithUpstream" property on trunk/debian
4. Run "fakeroot svn-buildpackage" in the trunk checkout
I would suggest keeping "upstream" source (i.e. the place we actually do
the work on piuparts) in /branches/upstream, and the debian stuff in
/trunk. Alternately, I *think* it would work with upstream in /trunk,
and some other dir for debian stuff. It seems that's a matter of
taste... In any case, whenever we want to make a release that involves
changes to piuparts itself and not just the packaging, we need to tag
/branches/upstream, export the tag, tar it up, and commit the tarball to
/tarballs. It'd be fairly simple to write a post-commit hook to do this
whenever a copy of /branches/upstream is made to /tags, I would think.
I'll start setting the repo up this way.
> Second, I'm thinking about an upload targetted for etch, only changing
> 1. change the maintainer field to set right name (we're the "piuparts
> developers team", not Lustre - this mailinglists name also should be fixed,
Sounds good to me -- also, I'm listed as an uploader but with a
non-existent email address: jsw at movingsucks.com should be
john at movingsucks.org . I'll go ahead and change this myself after
setting up the repo as mentioned above.
> 2. include the lists of currently known-failures in etch, which we can take
> from the "collab-qa" alioth project and add a pointer to there.
I guess I don't see the point of including the failures list in the
package itself. Providing a link seems appropriate, though.
More information about the Piuparts-devel