Skip to content

Conversation

@nrwahl2
Copy link

@nrwahl2 nrwahl2 commented Oct 29, 2025

No description provided.

@knet-jenkins
Copy link

knet-jenkins bot commented Oct 29, 2025

Can one of the project admins check and authorise this run please: https://ci.kronosnet.org/job/booth/job/booth-pipeline/job/PR-157/1/input

@nrwahl2
Copy link
Author

nrwahl2 commented Oct 29, 2025

@clumens Can you review this when you get a chance? Low priority

The copyrights need to be updated too, but I'm not sure how we want to do that. We haven't updated most of them in several years, and the copyright "owners" are all over the place. For example, src/booth.h has the following:

 * Copyright (C) 2011 Jiaju Zhang <jjzhang@suse.de>
 * Copyright (C) 2013-2014 Philipp Marek <philipp.marek@linbit.com>

Jiaju was the original committer, but there were several later committers besides.

Copy link
Member

@jfriesse jfriesse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of conditional NACK by me - I can fully agree having return type on their own line is more readable and I like this style too. But this change makes super hard to backport patches, makes git blame much harder and it is questionable if this change is really worth for quite old project such as booth. No matter what, if you think it is really worth the possible troubles, go ahead.

Looks like you've already solved the asciidoc problems (was in notify email, but I cannot find them now), right?

@nrwahl2
Copy link
Author

nrwahl2 commented Nov 4, 2025

But this change makes super hard to backport patches, makes git blame much harder and it is questionable if this change is really worth for quite old project such as booth. No matter what, if you think it is really worth the possible troubles, go ahead.

I appreciate your pointing this out :)

Speaking only for myself (as the apparent future maintainer of Booth), this tradeoff doesn't bother me much. Pacemaker is much larger than Booth, and we make formatting changes like this one regularly in Pacemaker. It does make backports a bit harder, and it makes git blame quite annoying (especially one series of commits in 2011 that changed indentation globally).

I view this as the first step in making Booth code easier for me to read and search, reducing the "cognitive load" of maintaining it. I'm already unfamiliar with the structure and with Unix network/socket programming beyond a very basic level. So I'll take whatever help I can give myself. I'd like to apply the same development guidelines to Booth that we strive for in Pacemaker.

Looks like you've already solved the asciidoc problems (was in notify email, but I cannot find them now), right?

Yes, that was embarrassing... Somehow I had an xmllint binary in /usr/local/sbin that was taking precedence. It wasn't provided by any package and I don't know where it came from. Maybe I built and installed libxml2 from source at some point and it didn't cause any problems until now. In any case, the xmllint from the standard libxml2 RPM doesn't seem to have this issue.

@knet-jenkins
Copy link

knet-jenkins bot commented Nov 4, 2025

Can one of the project admins check and authorise this run please: https://ci.kronosnet.org/job/booth/job/booth-pipeline/job/PR-157/2/input

src/transport.c Outdated

static int return_0_booth_site(struct booth_site *v __attribute((unused)))
static int
return_0_booth_site(struct booth_site *v __attribute((unused)))
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be __attribute__ for consistency with everywhere else.

I didn't realize gcc would even accept this syntax, and looking into that led me to https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html which says that __attribute__ is the old and busted syntax, and double brackets are the way to go. Of course, we don't do anything the modern way. I just thought it was interesting.

Copy link
Author

@nrwahl2 nrwahl2 Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the doc you linked:

More specifically, this [double bracket] syntax was first introduced in the C++11 language standard (see Language Standards Supported by GCC)

We support C99 and later, so we can't do this the modern way.

Add C++11 style attribute syntax[29] using double square brackets [[]].

https://en.wikipedia.org/wiki/C23_(C_standard_revision)#Syntax

@clumens
Copy link

clumens commented Nov 4, 2025

But this change makes super hard to backport patches, makes git blame much harder and it is questionable if this change is really worth for quite old project such as booth. No matter what, if you think it is really worth the possible troubles, go ahead.

I appreciate your pointing this out :)

Speaking only for myself (as the apparent future maintainer of Booth), this tradeoff doesn't bother me much. Pacemaker is much larger than Booth, and we make formatting changes like this one regularly in Pacemaker. It does make backports a bit harder, and it makes git blame quite annoying (especially one series of commits in 2011 that changed indentation globally).

I agree on making it harder to backport patches, and more importantly to finish off all those cleanups from poki (which I definitely think are worth continuing to merge in). It's still possible of course, it'll just take more manual intervention. Speaking as the outgoing maintainer of booth and the one who won't have to do this manual intervention, I'm fine with this PR if that's what you want to do.

@nrwahl2
Copy link
Author

nrwahl2 commented Nov 19, 2025

I agree on making it harder to backport patches, and more importantly to finish off all those cleanups from poki (which I definitely think are worth continuing to merge in). It's still possible of course, it'll just take more manual intervention. Speaking as the outgoing maintainer of booth and the one who won't have to do this manual intervention, I'm fine with this PR if that's what you want to do.

I just combed through all of those cleanups from poki and tried a cherry-pick or two. Considering the amount of merge conflicts there are already, I intend to go through each commit and apply it manually. Cherry-picking actually feels more difficult than that.

So the effect of this PR on those commits doesn't bother me.

This aligns with the Pacemaker Development guide and makes it easier to
locate a function's definition.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
These are intermediate files that are generated during man page
creation. They may be left behind in the event of an xmllint error, for
example.

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
Signed-off-by: Reid Wahl <nrwahl@protonmail.com>
@nrwahl2
Copy link
Author

nrwahl2 commented Nov 19, 2025

Updated to address review

@nrwahl2 nrwahl2 requested a review from clumens November 19, 2025 00:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants