No problem. Thanks for your time and inputs.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3072#issuecomment-2095342827
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #3072.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3072#event-12710658133
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Sorry but I agree with @nwalfield , this is just strange churn for churn's
sake. Like advertising use of goto but then still using return for the cases
that *could* use a central clean-up point. Even the changes that I could use
because I suggested them are mixed with unrelated other changes,
@nwalfield Thanks for reviewing.
> and some are weird, like having #define LEN 102400 // 100 * 1024
It would help me understand things better if you explain a bit on why it is
weird.
My intent behind the change is, why calculate something on every run which can
be used directly?
I'm completely
I've taken a look at this MR, and it's basically churn. Some of the changes
are coding style, and some are opinionated, and some are weird, like having
`#define LEN 102400 // 100 * 1024`. If I have a vote, this is a nack from me.
--
Reply to this email directly or view it on GitHub:
@sshedi pushed 8 commits.
e2938095b9f376e58397acceb8d3c5185928c58c rpmpgppubkeyfingerprint.c: use
rpmGetCwd
3577dc5c43c912d613fff3ac9df21a41ca0c746c rpmpgppubkeyfingerprint.c: use static
buffer instead of malloc
a034d6c8d31caf1bf6b47ca3aa5d1d48f67341e2 rpmpgppubkeyfingerprint.c: move
@pmatilai thanks for all the inputs. I have tried addressing all of them.
Please let me know if I have missed anything.
@ffesti thank you for reviewing my earlier PR.
--
Reply to this email directly or view it on GitHub:
