[Prophet] Prophet and SD maintenance

[Ioan Rogers]

On Fri, 2013-02-15 at 00:10 +0100, Jonas Smedegaard wrote:
> Quoting Ioan Rogers (2013-02-14 21:47:00)
> > On Thu, 2013-02-14 at 11:43 +0100, Jonas Smedegaard wrote:
> > > Quoting Ioan Rogers (2013-02-13 21:33:56)

> CDBS is not a single-purpose tool like quilt or the individual dh_* 
> commands, but also not quite as invasive as the short-form dh command: 
> CDBS is a collection of make snippets - you continue to use the 
> debian/rules file like makefile that it really is - it does not invent a 
> new language as dh does.
> 

Thanks. I might actually look further into it one day!

> > 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?
> 
> That does not collide with CDBS, but sounds like a bad idea IMO: That 
> sounds like blurring the line between upstream and Debian packaging, 
> which I find unwise.  We really want the upstream code used as 
> widespread as possible which means also in non-Debian environments - and 
> releasing as versioned tarballs is still a quite sensible way to do that 
> also nowadays - git tags do not render tarballs obsolete!
> 

Oh, no, that wasn't my intent. I'll still put tarballs on CPAN. In cases
where upstream == packager, I find it preferable to `git checkout
debian`, rather than having to import a tarball just to end up with two
separate repos containing much the same code. But you're the packager
now, so that's 5 seconds of your life! :-) 

> ..and from Debian perspective, basing the packaging process in upstream 
> tarballs also makes good sense.  There is some experimental work on 
> basing packaging in e.g. git, but that is *experimental* and may not 
> ever become supported for official Debian structures.  So also here the 
> good old tarballs are not obsolete.
> 
> 
AFAICT the 3.0 (git) is mostly useless as ftp-masters won't touch it, so
I do use native and gbp generated orig.tars.

> I had a look at your packaging work, and honestly I don't really like 
> your approach, so will not merge but do separate work for now. I'd be 
> happy to elaborate if you want, but if you would rather hack on upstream 
> code than dive into packaging nitpicking now, then I shall not bother 
> you with that, just look forward to your exciting upcoming releases :-)
> 

Ouch! :-) Please do tell me, I'm trying to improve my packaging skills.

> NB! I suggest you consider adopting upstream my patch 1001 for prophet: 
> Judging from your symlink change in your packaging work, you may not 
> have noticed this elegant mechanism Christine added, which my patch 
> extends.
> 

Hrrrmmm, I did see it, and IIRC (October was long time ago) I think the
symlink route was more expedient. In the future I want prophet to only
handle the data and not force its UI choices on other developers, so I
will ideally be removing the JS.

> Generally when I name patches, those starting with 1 are candidates for 
> upstream adoption.

Noted.

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/20130218/456480af/attachment.pgp>