Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: INN indentation (Perry E. Metzger)
2. Re: INN indentation (Richard Kettlewell)
3. Re: INN indentation (Julien ?LIE)
4. Re: INN snapshot changes (Russ Allbery)
5. Re: Discussion about Cancel-Lock support (Russ Allbery)
6. Re: INN indentation (Russ Allbery)
7. Re: INN indentation (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sun, 19 Sep 2021 08:02:14 -0400
From: "Perry E. Metzger" <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Delurking for a moment...
On 9/19/21 06:26, Richard Kettlewell wrote:
>
> (My personal preference would be to completely ban the tab character
> from source code, enforced with build time tests, since the meaning of
> the tab character depends on local configuration and it is,
> empirically, unrealistic to assume that everyone will share the same
> configuration.
Git offers the ability to check constraints like this on check-in.
I agree with the notion of banning tabs characters from from source
code. This doesn't of course mean that one doesn't still use the tab key
while typing in one's editor, just that one configures it to indent with
spaces. See, for example:
https://www.jwz.org/doc/tabs-vs-spaces.html
for a thorough discussion of the options in the choice space.
If, however, such a thing is going to be done, it would mean a lot of
whitespace changes to review. Luckily, many modern versions of diff
(including that in git) can be configured to ignore whitespace changes
when diffing, to make review of such modifications easier. That said,
the bigger issue is that large changes like this often break development
branches quite badly, though again, the ability to do
whitespace-indifferent diffs can help somewhat.
Perry
------------------------------
Message: 2
Date: Sun, 19 Sep 2021 14:00:36 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 19/09/2021 13:02, Perry E. Metzger wrote:
> Delurking for a moment...
>
> On 9/19/21 06:26, Richard Kettlewell wrote:
>>
>> (My personal preference would be to completely ban the tab character
>> from source code, enforced with build time tests, since the meaning of
>> the tab character depends on local configuration and it is,
>> empirically, unrealistic to assume that everyone will share the same
>> configuration.
>
> Git offers the ability to check constraints like this on check-in.
That's a good point, although I don't know if you can enable those on
GitHub in the same way as a local repo.
https://github.com/InterNetNews/inn/blob/main/ci/test would be the place
for it if not.
> I agree with the notion of banning tabs characters from from source
> code. This doesn't of course mean that one doesn't still use the tab key
> while typing in one's editor, just that one configures it to indent with
> spaces. See, for example:
>
> https://www.jwz.org/doc/tabs-vs-spaces.html
>
> for a thorough discussion of the options in the choice space.
>
> If, however, such a thing is going to be done, it would mean a lot of
> whitespace changes to review. Luckily, many modern versions of diff
> (including that in git) can be configured to ignore whitespace changes
> when diffing, to make review of such modifications easier. That said,
> the bigger issue is that large changes like this often break development
> branches quite badly, though again, the ability to do
> whitespace-indifferent diffs can help somewhat.
Also good points.
In my view the way to make any change would be to use an agreed script
(or one-liner). That addresses both issues as follows:
1) Review can be done by the reviewer reviewing the script and then
running it independently to verify that it produces the same result,
rather than by attempting to review a giant diff.
2) Long-lived branches, or short-lived branches that happen to overlap
the change, can be repaired by running the script, effectively carrying
out the same change in the branch.
ttfn/rjk
------------------------------
Message: 3
Date: Sun, 19 Sep 2021 15:29:15 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Richard,
> The current stated style is, in hacking.pod:
>
> ? Use a roughly BSD indentation style but with four-space indents.? This
> ? means no space before the parenthesis around function arguments, open
> ? brace on the same line as if/while/for, and close and open brace on
> ? the same line as else.
>
> However the reality is slightly more complicated: many files use tabs
> and spaces interchangeably, apparently with an assumption that the tab
> character represents 8 spaces, despite the coding style saying indent is
> 4 spaces.
Hmm yes, and I admit to be a bit faulty there because I have tabstop set
at 8 in vim. Source code seems to have initially written with 8-space
indents. See for instance innfeed/imap_connection.c where the first
level of indentation is 4 spaces, and the second level is a tabulation.
That's why I then used to assume a tabulation represented 8 spaces
when modifying existing code.
Regarding indentation, what has been done until now is always use spaces
for new code, and convert tabs to spaces when modifying lines in
existing code.
Note that some tabulations may still be needed in source code,
especially outside indentation. I have in mind control/docheckgroups
which for instance contains:
${SED} 's/ [ ]*/ /'
as \t appeared to be non portable in all sed implementations.
--
Julien ?LIE
??La vie est un sommeil, l'amour en est le r?ve et vous aurez v?cu si
vous avez aim?.?? (Alfred de Musset)
------------------------------
Message: 4
Date: Sun, 19 Sep 2021 08:34:08 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: INN snapshot changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Do you know how many snapshots on changes will be retained for each
> branch? (purge after a certain date? for instance 3 months but always
> keep at least 1 snapshot? It would for instance mean for the FreeBSD
> inn-current port that a notification of inexistent snapshot will not
> happen before at least 3 months, which seems reasonable.)
I'm currently keeping eight snapshots. The count is easy to change; doing
something time-based is possible but would require more thinking.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 5
Date: Sun, 19 Sep 2021 08:37:18 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
>> I'm not sure that I understand the difference between canlockuser and
>> extracanlockuser. They both result in sending a hash, and they are
>> both valid for verifying hashes, correct? If that's the case, it may
>> be simpler to remove the extra* parameters and just make the values
>> lists.
> The idea behind was to send a hash only for canlock* and verify hashes
> for both canlock* and extra* but I agree it is a bit complex and
> confusing. During key rotation, we can still go on send both hashes,
> and verify both hashes, then at one time remove the old password. Looks
> like simpler indeed, with canlock* lists.
Oh, I see. In that case, maybe change extracanlockuser to
canlockverifyuser? That makes it clearer the extra user is for
verification only.
> Yep.
> So in a nutshell the best design would be an inn.conf parameter:
> secretsfile: <pathetc>/secrets.conf
> With secrets.conf like:
> cancels {
> canlockuser: [ password ]
> canlockadmin: [ password anotherpassword ]
> }
> # And other groups to come when merging other secrets.
Yeah, that would work. I'm not sure the extra configuration of specifying
a path to the file is needed, but I guess since it contains secrets maybe
that would be useful.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 6
Date: Sun, 19 Sep 2021 08:43:33 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain
Richard Kettlewell <[email protected]> writes:
> However the reality is slightly more complicated: many files use tabs
> and spaces interchangeably, apparently with an assumption that the tab
> character represents 8 spaces, despite the coding style saying indent is
> 4 spaces.
The tabs are all legacy; I was removing them when I did a comprehensive
revisit of a file back when I was rewriting more of the code and adding
tests, but didn't get to most of them.
My preference is to never write a tab to disk in source code. I think it
should be a purely in-editor command represented by spaces on disk.
> Would it be possible to adopt an indent rule in which either tabs match
> the indent depth, or tabs are not used at all, and reformat the source
> code accordingly?
For my personal projects, I've started using clang-format to just reformat
all of the source code and keep it consistently formatted. It requires
some work up-front to mark some code blocks to not reformat, because it
messes up a lot of code that's carefully laid out to make it easier to
read, but once you're done you can then stop thinking about it. It's very
similar to using black for Python. One can then add it to the tests and
reject malformatted diffs, or even provide a Git hook to automatically fix
formatting.
It's unfortunately a big flag day that breaks backporting of diffs, so
we'd probably want to do the same thing in both the main and 2.6 branches
at the same time, and it makes git annotate kind of a mess unless you
ignore whitespace. But I thought it was worth it for my personal projects
to stop thinking about formatting.
For the record, here's the .clang-format file I use for my personal
projects:
# Configuration for clang-format automated reformatting. -*- yaml -*-
#
# The canonical version of this file is maintained in the rra-c-util package,
# which can be found at <https://www.eyrie.org/~eagle/software/rra-c-util/>.
#
# Copyright 2020 Russ Allbery <[email protected]>
#
# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved. This file is offered as-is, without any
# warranty.
#
# SPDX-License-Identifier: FSFAP
---
Language: Cpp
BasedOnStyle: LLVM
AlignConsecutiveMacros: true
AlignEscapedNewlines: Left
AlwaysBreakAfterReturnType: AllDefinitions
BreakBeforeBinaryOperators: NonAssignment
BreakBeforeBraces: WebKit
ColumnLimit: 79
IndentPPDirectives: AfterHash
IndentWidth: 4
IndentWrappedFunctionNames: false
MaxEmptyLinesToKeep: 2
SpaceAfterCStyleCast: true
---
My personal style is slightly different than INN's, but they're relatively
close. (INN has some unusual conventions for comment formatting.) The
biggest thing that it changed in my other projects was using four-space
indentation for nested C preprocessor directives.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 7
Date: Sun, 19 Sep 2021 09:10:10 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain
Russ Allbery <[email protected]> writes:
> For the record, here's the .clang-format file I use for my personal
> projects:
Oh, and if anyone wants to try this, make sure you have clang-format
installed (on Debian it's a separate package), save .clang-format at the
root of the tree, and then run:
find . -name '*.[ch]' -print | xargs clang-format -style=file -i
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 133, Issue 11
********************************************
