monero-project/monero #6376 needs a review

Snipa, you around?

We can do a small meeting in 15? Just a recap of this last release.

So, meeting? there is also next cli/daemon release to talk about afaik

I'm here if we want a meeting

Here

hi

here is a list of PRs for the next release: paste.debian.net/hidden/7f5d299c

AFAIK all are reviewed, 6376 is in the process of getting reviewed

after this release we would start working on v0.15.1.0 from master branch

I think we can also add 6312

which will include D++ and maybe the ASM speedups if everything gets reviewed.

so we have some more strings translated and i can unlock the CLI on weblate

you have to PR against v0.15 branch

So this a release "small and fast", and therefore including only a minimum, right?

yes

ah ok. I thought we were releasing from master

it's not that important to have 5312 in this release, more important to have it merged soon

no, v0.15.1.0 will be from master, v0.15.0.5 from release-v0.15

Ah ok. Got it now

v0.15.0.4 was first release without fluffy, it went quite well

but we are still fighting a bit with static Qt builds

what's the timeline for 0.15.1.0?

question for the meeting: does it make sense to continue keeping CLI and GUI in sync with version numbers?

they're not perfectly in sync right now

We did not keep them in sync.

CLI is behind GUI

they kinda are in sync, just CLI releases where only GUI stuff gets changed get skipped

but IMO yes, we should keep them close, since the GUI includes the CLI

but now CLI goes from .0.1 to 0.5 to keep in sync with GUI

They're *mostly* in sync because we release roughly at the same time.

If no sync I think completely different version numbers would be an idea, to avoid confusion.

IIRC GUI folks wanted to release more often

"GUI Version 1.2, based on Monero Core 15.1.0.0"

ugh

keep major version numbers in sync

the current system works ok so we don’t have to change it

And minor, since it's the one that gets bumped on forks.

or, use the same version numbers as are feature-compatible

just maybe if someone has a better idea

I think current scheme ain't broke, don't fix it

It's maybe a little broken because it confuses some people ...

If not in perfect sync

it will never be in perfect sync unless we release CLI updates with no changes :P

people should be smart enough to know that X.x.x.y and X.x.x.z are only a minor difference

yep

agree

Minor can include security fixes here. It's sensible to ask for confirmation I guess.

ErCiccione[m]: timeline for v0.15.1.0: ~1 month

security fixes that we don't also release in CLI?

seems unlikely

Thanks selsta

I think it will need good testing if we branch from master

Minor version bumps can include security fixes in the CLI tools. It's sensible to ask for confirmation that the version you have is really the latest one I guess.

selsta: Last time we managed to have a proper code freeze. If we keep it that way we should be fine IMHO

Well, with 0.15.1 in about 1 month, and a code freeze, poor snipa will have to merge day and night

Not really related, but i think a clarification from core about hard forks it's needed. It's still not clear to me if we are keeping the 6 months schedule, if we are going to 9 months HF, or even 1 year.

if you download a GUI release you get a CLI bundled in. why would you think they are not up to date with each other?

ErCiccione[m]: latest I heard is we continue to release every 6 months, but the hardfork may be skipped if we have no consensus changes to push

rbrunner: We also have luigi :D

Ah, for the GUI then

But I think a lot is waiting anyway, right?

hyc: Yeah but i think we need some official statement or something. Last time we released after 9 months IIRC

So, what's the official take? anybody from core around? fluffypony binaryfate articmine luigi1111

what last time, what 9 months?

I like the just work on things and fork when necessary approach. Having a month specific schedule is difficult for OSS.

Ask binarypony1111.

hyc: last hard fork happened after 9 months, but there was no release after 6. the initial idea was to release anyway after 6 months to keep the schedule, but that didn't really happen and there were so many discussions about it in the meantime, that i don't know where we stand now.

last hardfork, November 30?

IMHO we stand where selsa just said :)

Aim, but don't try to shoehorn if you see you can't hit the aimed region.

sorry no, i menat the one before. I'm getting confused now

Is any pressing consensus change waiting anywhere?

I think this question is moot. We had one off-schedule release but we've been on track.

CLSAG :D

But it's getting kicked in the butt again :(

Ready to go?

AFAIK yes.

I thought CLSAG won't go until there's been a paid formal audit

You mean some issues surfaced lately?

Well, I'd have to bump the fork checks for 13 instead of 12.

Yes. And no audit is anywhere near.

alright, maybe i have my timings wrong

One company said they could do it.

They don't happen from themselves in any case. Maybe mount some drive ...

AFAIK MRL does not want to do an audit for COI reasons (?)

so now nothing is happening

unless someone else organizes one

What is "COI"?

I don't understand the conflict

Conflict of interest.

Ah, thanks

just forwarding what I read in #monero-research-lab

i think we should tall about a new schedule. or just skip this fork and consider it a talk about a new schedule

sgp_ knows more maybe and sarang

alright than i wasn't crazy. I remember the discussion about changing schedule happening

is dandelion++ going to be in this release? will v0.15.0 nodes simply broadcast any stem-phase txns they receive?

I am quite sure it's fully interoperable

no D++ will be included with v0.15.1.0

ok

next release will be v0.15.0.5

and we will tag tomorrow or do

so*

sounds fine

once moo is happy with 6375

so how do we get CLSAG audited

probably the same way we got randomX audited. somebody solicits statements of work from auditing companies

and then we start a CCS to pay for the audits

AFAIK there is still 1 offer for $15k

code and math review

that has been done and we have 1 company that will do both the math and implementation

how many do we think are needed?

1

I asked that question at last MRL meeting

no answer but I like selsta's answer :)

the submitted CLSAG somewhere and it got reviews, so we should also consider that

they*

don’t know the exact scientific wording :)

journal?

the math they are comfortable with, more a matter of implementation

moneromooo is CLSAG a large code change? how many audits would you prefer?

Depends what you call large... sarang says it's conceptually simple really.

would you be comfortable with 1 audit?

+580 lines. Yes.

But it's not me that has to be comfortable :)

And +1k lines for the plugging into monero :o

OK, two thirds of that is tests.

Ah yes, there might be some consensus changes related to minimum fee in an upcoming hardfork. ArticMine is researching an idea afaik (there is also my idea on research-lab issues)

unless sarang suraeNoether or someone else speaks up against 1 audit I think we should go with one

1 audit seems good to me, clsag isn't too crazy

UkoeHB_: ok so we would have CLSAG + minimum fee changes

Well, the audit itself would take some time, presumably. Even if it started asap.

But we could push any fork, also presumably...

hey, don't want to bother you guys but could someone confirm if the fingerprint of binaryfate's GPG key is 81AC 591F E9C4 B65C 5806 AFC3 F0AF 4D46 2A0B DF92?

Min fee changes only really matter with higher tx volume, and if multisig is a lot more advanced, so no big rush there imo

TinusMars: yes

thanks

It should be in the monero repo, where it was checked before being included.

The updated guide with the updated fingerprint was also merged. Waiting for getmonero to be updated repo.getmonero.org/monero-project/monero-site/-/merge_requests/1242

meeting over or there is something else to talk about?

yep meeting over

8-)Dandelion++ test?

SOunds like lots of merges to review. Y'all still have meetings way too early in the day for me on the weekends. :P Night owl, west-coast US so my timings are generally all off.

selsta: the net logs PRs are good to go.

ok nice

merge list for release-v0.15 branch: paste.debian.net/hidden/7f5d299c

^ Snipa luigi1111, whoever of you has time first. Would be nice to get the v0.15.0.5 tag out in the next days. ty