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

[Stef]

On 21/11/2013 20:31, Paul Newall wrote:
> 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
>
     Hello,

     I also think it could be generated. My only doubt is that the 
Changelog file allow us to summarize things.

Regards,
     Stef