Include doc and manpage in Debian package.

[fidergo-stephane-gourichon]

@ssokolow this follows your request on #106 .

How about some credits in the documentation?

Hints from git history. What do you think?

git log --pretty=%an | sort | uniq -c | sort -nr

    376 Stephan Sokolow
     12 Stéphane Gourichon
      3 Yuting Xiao
      3 Justin
      2 wmax
      1 soaxelbrooke
      1 Valentin Agachi
      1 Valdis Vitolins
      1 Oliver Gerlich
      1 Matthias Putz
      1 David Stygstra

[coveralls]

Coverage remained the same at 61.029% when pulling b507d53 on fidergo-stephane-gourichon:feature_debian_package into a0098e4 on ssokolow:master.

[ssokolow]

I've been meaning to go through and put together an AUTHORS file for the repository as a whole (which would also go in /usr/share/docs/). Thanks for reminding me.

There is already one for the docs at docs/AUTHORS since the docs were much simpler. (Just me, David Stygstra for the first bunch of illustrations, and the usual attributions for any icons and other bits I used.)

I'm on a bit of an odd schedule right now and need to get to sleep, but, tomorrow, I'll start looking into what the best way is to reconcile the convention of having an AUTHORS file with also having that information in the docs.

(Maybe I could put together something which runs Sphinx's make text on just a single authors.rst page and stores the output as AUTHORS in the repository root. Then I could add instructions relating to it in the developer's guide section of the manual.)

[ssokolow]

Done.

• https://github.com/ssokolow/quicktile/blob/master/AUTHORS
• http://ssokolow.com/quicktile/authors/index.html
• http://ssokolow.com/quicktile/developing.html#adding-yourself-to-the-authors-list

That AUTHORS file can now be added to the Debian packaging so that there's something in /usr/share/doc that doesn't require an HTML parser to display.

(The HTML version needed to be authors/index.html rather than authors.html to work around limitations in what subset of a document Sphinx can be induced to render in isolation for text output.)

[ssokolow]

Oops. Almost forgot about a couple of credits for people whose names don't show up in git log. (Only in docstrings and code comments.)

Fixed.

[fidergo-stephane-gourichon]

Great! I rebased the branch of the PR.

What version number do you want? I guess 0.4.0gtk3 is no longer relevant. 0.4.0? 0.4.1?

[ssokolow]

In the short term, I'd prefer whatever this command outputs so the package name agrees with setup.py and anything else in QuickTile that reports its version:

./setup.py --version

(I haven't bumped it from 0.4.0 to 0.4.1 yet because there have been no changes to the code yet... just to the site/documentation.)

In the long term, I'll want to try to reduce the amount of changelog duplication too.

[fidergo-stephane-gourichon]

In the short term, I'd prefer whatever this command outputs so the package name agrees with setup.py and anything else in QuickTile that reports its version:

Makes sense.
It currently returns 0.4, not 0.4.0. But the ChangeLog says 0.4.0.
So I guess it's what you want for the formal Debian package number.

In the long term, I'll want to try to reduce the amount of changelog duplication too.

Agreed. DRY principle. Some projects maintain a "short" changelog, concise, no details, and a "long" changelog. Git history feels like a long changelog anyway.

[ssokolow]

Makes sense.
It currently returns 0.4, not 0.4.0. But the ChangeLog says 0.4.0.
So I guess it's what you want for the formal Debian package number.

The first thing I'd want to do is check whether there's a Debian policy on the matter before making a decision, then let that inform my decision on which choice to unify both on.

Agreed. DRY principle. Some projects maintain a "short" changelog, concise, no details, and a "long" changelog. Git history feels like a long changelog anyway.

My git history would be a very long changelog, so definitely not that. I was thinking more of how to minimize duplication between the ChangeLog file and the Debian changelog.

[ssokolow]

There are a couple of things that look questionable to me, but thanks for the work. I've been meaning to get back to work on QuickTile but I've been bogged down preparing the house for winter for a while.

(And, prior to that, the year has just been a mess for me. I didn't start to get productive on non-essentials until two months ago.)

[ssokolow]

Do you have a specific example of why this change is necessary?

[ssokolow]

Ugh. I'm not used to GitHub's reviews. I'll have to remember to mark the last line rather than the first next time.

[ssokolow]

You may be stephane, but I'm ssokolow and have no such user and group on my system. It looks like you're either missing username and group lookups here or should use names that make it more clear that all that matters is matching the external UID and GID.

[fidergo-stephane-gourichon]

Oops! Of course this is unacceptable for published software. Probably a local expedient that I forgot to refine.