[sane-devel] [sane-commit] [sane-backends] 01/01: sane-desc: fix faulty udev logic for SCSI devices

[Nils Philippsen]

Hi Stef,

On Thu, 2013-11-21 at 07:12 +0100, Stef wrote:
>      you also have to change the expected results in the testsuite to 
> take into account this change. 'make check' will now fail. I have 
> updated the testsuite to handle git version number change so you can 
> update it easily.

ahh sorry, I wasn't aware that the test suite checked this. I'll update
the reference files shortly.

>      We have the usage of updating sane-backends/Changelog file on 
> changes, would you mind to also update it ? Quite a number of your 
> commits summary aren't present.

Hmm, my git habits strike again I guess. Manually maintaining a change
log seems a bit redundant to me because we (should) enter equivalent
information in git commit messages already (and I'm guilty of some
redundancy myself, prefixing my commit messages with the affected
backend/subsystem).

Additionally, updating ChangeLog in git with the commit is a source for
conflicts when merging or cherry-picking (though the latter is largely a
packager's problem I guess).

I can add the missing entries for my recent changes, but if there's no
strong aversion against it I'd rather implement generating the ChangeLog
file from the recent git commits (i.e. since the last tagged version).
This is for instance done in GIMP -- they haven't bothered emulating the
GNU ChangeLog style, though.

The idea I have is that the current ChangeLog need not even be kept in
git, instead generate it on the fly from the commit messages so far, and
add it to the repository as ChangeLog-$version whenever there's a
release (at which point it doesn't get changed anymore).

Here are the potential problems I can think of that would need to be
addressed first:

1) I've seen people use one email address in the git commits and another
in ChangeLog.
2) Similarly, some people use obfuscated email addresses in the
ChangeLog but plain ones in commits.
3) We need to decide what text gets put into ChangeLog, we probably
don't want to have walls of text in there.
4) If different branches are merged it results in merge commits and
non-linear history.

1), 2) shouldn't be real problems, we should just use one address
(configure user.email accordingly either globally or just for the
repository), obfuscated or not (I don't see the point in obfuscating
though, as they are plainly visible in the Alioth SCM browser commit
messages ;-)). IMO, git solves one half of 4) neatly, it seems to sort
branches according to their newest commit. I don't have a strong opinion
on whether or not we want merges documented in ChangeLog, or ignore the
merge commits, "git log" can do either fine. Regarding the non-linear
history involved with merges, "git log" has a number of ordering
options.

For 3) I think we should simply stick to the conventional git commit
format: one short subject/summary line, optionally a blank line plus
longer description, then simply take the subject/summary.

In the time since I've started writing this reply I've whipped up a
small shell(*) script which should format git commit logs into more or
less the GNU ChangeLog format which we use in SANE:

http://paste.fedoraproject.org/55706/

(*): not by preference, I just wanted to avoid introducing yet another
scripting language

To test, run it from inside a git repository and specify a commit hash
or tag from where to start on the command line. It ignores changes only
done to ChangeLog ;-). Here's sample output, from the release of 1.0.24
to the current state of master:

http://paste.fedoraproject.org/55708/04355913/

What do you think? If you're okay with this, I can give integrating it
with make dist* a whirl.

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011