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

[Paul Newall]

On 21/11/13 14:29, Nils Philippsen wrote:
> 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
I agree that making entries in both git and the changelog feels redundant.
However, the simple text format of the changelog is easy for people 
unfamiliar with git to find and read.
I came to sane development with no previous experience of either auto 
configure / auto make or git and it was a very steep learning curve. 
Being able to just read peoples commit messages in a text file makes 
life easier for the novice.
Paul