Open fidergo-stephane-gourichon opened 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.)
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.)
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.
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?
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.
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.
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 this follows your request on #106 .
How about some credits in the documentation?
Hints from git history. What do you think?