Re: pandoc depwaits
+++ Joachim Breitner [Jul 29 09 02:09 ]:
> [Moving this back on the list]
> Am Dienstag, den 28.07.2009, 16:50 -0700 schrieb John MacFarlane:
> > +++ Jonas Smedegaard [Jul 28 09 11:35 ]:
> > > On Tue, Jul 28, 2009 at 10:21:19AM +0200, Joachim Breitner wrote:
> > > >It’s always a bit tricky to take over a packer properly. But if he does
> > > >not respond, and his packages are uninstallable right now, that is
> > > >sufficient to do NMUs at least. So just go ahead and work on it, and
> > > >it’s dependencies as needed, but do it with NMUs and leave him in the
> > > >Maintainer field for now.
> > > >
> > > >I’m CC’ing another DD who today asked for the state of pandoc, and
> > > >might be interested in helping.
> > >
> > > I agree with Joachim that lack of activity on its own is a fine excuse
> > > for NMUing a package.
> > >
> > > Another option which I recommend here is to do a "friendly takeover":
> > > Hinting as "O"rphaned and then "RFA"dopting it is only necessary if the
> > > new maintainer is unknown. An explicit aknowledgement of letting go of
> > > maintainership need not be public - especially when backed by implicitly
> > > demonstrating lack of interest in the package.
> > >
> > > So, in short, I strongly recommend to simply prepare and upload a new
> > > release with new maintainer, mentioning "friendly takeover" in the
> > > changelog and nicely thanking the former maintainer for his great work
> > > in the past.
> > >
> > > I am, as Joachim says, an active user of pandoc, but have no knowledge
> > > of Haskell (and no strong interest in learning it either). I do have
> > > quite a bit of knowledge of packaging in general, as I participate in
> > > development and package maintainance of CDBS.
> > >
> > > I would be happy to join a team for maintaining the Pandoc packaging, if
> > > the package would use CDBS (as opposed to classic explicit debian/rules
> > > rules or debhelper v7 shortenings).
> > Jonas,
> > That's terrific! I don't know too much about debian packaging, so I
> > don't understand the part after the 'if'. But I can handle the Haskell
> > part if you can handle the debian-specific part. Pandoc now has a
> > fairly standard cabal build process, so (except for a few details like
> > man pages and wrapper scripts) it should be much like any other
> > cabalized Haskell package. I think the debian haskell team has a
> > fairly standard way of doing these things, so it should be mostly a
> > matter of copying an existing package that is done in the standard
> > way.
> > Note that pandoc 0.46, currently in debian, is a native debian package,
> > but going forward it won't be.
> > Pandoc depends on two other packages that may need work: pcre-light
> > and highlighting-kate. Both were maintained by Recai Oktas. I'm the
> > upstream developer for highlighting-kate; pcre-light is by Don Stewart.
> > > As for workspace for team work, I would prefer to use Git (as opposed to
> > > SVN or other VCSes) and would suggest to not create mailinglist or any
> > > other infrastructure at first, other than simply creating the VCS. This
> > > also means that we need not request an Alioth group - just use
> > > collab-maint.
> great to see pandoc in good hands. Note that pandoc is also a haskell
> library, so I would appreciate if you would stay in touch with
> ddebian-haskell. At the moment, nothing Build-Depends on pandoc, but
> when that changes, uploads need to be a bit coordinated. Just make sure
> you inform d-haskell about important changes.
> I’m adopting the two dependencies, pcre-light and highlighting-kate, for
> the Debian Haskell Group, so that you are ready to go.
I forgot to mention another pandoc dependency: zip-archive. It's a
standard cabalized library, and I think all of its dependencies are
I haven't heard from Jonas -- not sure if he is interested in working on
the pandoc package. If not, I can try it myself, using cpphs as a
model, but I may need some guidance.