ssokolow / quicktile

Adds window-tiling hotkeys to any X11 desktop. (An analogue to WinSplit Revolution for people who don't want to use Compiz Grid)
https://ssokolow.com/quicktile/
GNU General Public License v2.0
860 stars 78 forks source link

Include doc and manpage in Debian package. #112

Open fidergo-stephane-gourichon opened 4 years ago

fidergo-stephane-gourichon commented 4 years ago

@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 commented 4 years ago

Coverage Status

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

ssokolow commented 4 years ago

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 commented 4 years ago

Done.

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.