[Piuparts-devel] piuparts team development / documentation upload for etch

John Wright 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:
> Hi,
> 
> 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.
     /tarballs/piuparts_0.20.orig.tar.gz)
  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 
> documentation: 
> 
> 1. change the maintainer field to set right name (we're the "piuparts 
> developers team", not Lustre - this mailinglists name also should be fixed, 
> btw) 

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.

-- 
John Wright



More information about the Piuparts-devel mailing list