[Prophet] Prophet and SD maintenance

[Ioan Rogers]

On Thu, 2013-02-14 at 11:43 +0100, Jonas Smedegaard wrote:
Quoting Ioan Rogers (2013-02-13 21:33:56)
> 
> Collision alert!!! Sorry Jonas, I'd already migrated the packages
over 
> > to debian-perl, but apparently didn't remove the original repo. I
need 
> > a DD to check my work before I removed the original.
> 
> Arrgh.
> 
> That is indeed collission of work: My prepared Prophet 0.750-1 has
just 
> been accepted targeted Debian unstable a moment ago.  I have not yet 
> done an official package update of SD with the changes I have tested 
> unofficially, and will put that on hold for now...
> 
> Could you please provide git URLs for the work you have prepared?
> 
ssh://git.debian.org/git/pkg-perl/packages/prophet.git
ssh://git.debian.org/git/pkg-perl/packages/sd.git

Upstream: https://gitorious.org/prophet

> Was using `takeover-for-pkg-perl.sh` the right thing to do, or should 
> > I have just moved the repo on alioth?
> 
> What might have avoided duplicate work was if you had been more
vocal: 
> Before doing serious work on an official update of the Debian package
I 
> searched for activity on SD and Prophet (including at the debian-perl 
> mailinglist), and found no concrete progress :-(


Yes, sorry again. The only discussion that really happened was on
#593134, but that doesn't mention the new URLs. They do show up on 
http://pet.debian.net/pkg-perl/pet.cgi, but you wouldn't look there if I
don't tell anyone they moved.

> I'd like to do one maintenance/bug fixing release upstream which
would 
> > also fix any outstanding debian bugs, so we shouldn't need CDBS or
any 
> > deb patches.
> 
> I don't follow how upstream bugfixing renders CDBS irrelevant.  I use 
> CDBS consistently across all packages that I maintain because I find
it most efficient to work that way. 
 
Ahh, I had the impression that CDBS was an equivalent of quilt not dh.
Apparently not!

I am not open to change my working 
> habits at the moment, but I do recognize that not all find CDBS 
> convenient as I do, and I am perfectly ok either a) taking time to
guide 
> you in using CDBS, or b) let you ignore CDBS and leave those parts to 
> me, or c) step down from being involved in these packages.
 
 
a) I'm definitely not interested in this option. Having only just
realised what CDBS *is*, I have no opinion on its convenience. It's more
a time problem. I've never had any technical issues building debs for
work and personal use, but once I started contributing to debian-perl
all my monthly time allocation went on reading docs and chasing
upstream/3rd-party copyright issues. So I'm very much demotivated to
learn another packaging tool if I can avoid it :-/

b) I'd like to merge the debian and upstream repos, drop pristine-tar
and have a debian branch, building with git-buildpackage. Is this okay
with CDBS and/or your workflow?

c) Nope, not an option. I need help! :-)

I agree debian-perl team is ideal place to have the packaging.  Only 
> reason I did current release without moving is that I expect that
move 
> to involve a source package rename to conform to team policy, and it 
> would be better to do that after eliminating most possible open bugs.
 
I didn't even think of that. I was just following the adoption docs.

Looking forward to know if you are interested in collaborating with me 
> (which implies using CDBS for packaging), would prefer to find others 
> that are ok using the short-form dh sequencer, or perhaps are ok
leaving 
> the Debian packaging to me and you then concentrate on upstream work.


Hmm, I'll take the third option now, if you're happy with that. Do you
want to merge the two prophet repos together on alioth, or should I do
it? I believe my sd package was ready to go as soon as prophet is out.

Thanks

Ioan




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.bestpractical.com/pipermail/prophet/attachments/20130214/a3332102/attachment.pgp>