07:55:56 <binaryFate> GUI v0.16.0.2 is now available on getmonero.org
09:44:54 <ErCiccione[m]> Is there any "known issue" in this release? If there is something i will add it to the download page
10:45:21 -xmr-pr- moneromooo-monero opened pull request #6703: daemon: don't print "(pruned)" for coinbase txes
10:45:21 -xmr-pr- > https://github.com/monero-project/monero/pull/6703
16:16:02 <sarang> More good news on the CLSAG front
16:16:19 <sarang> I heard back from ph4r05 regarding Trezor support
16:16:34 <sarang> and they said that the Trezor-side CLSAG code is already done and reviewed
16:17:07 <sarang> So once a block height is set and the Monero code is merged, they will only need to do a small client PR to enable it
16:17:35 <moneromooo> Great.
16:17:36 <sarang> I'd also like to revisit the "upgrade checklist" idea that I brought up a while back
16:21:40 <ErCiccione[m]> The upgrade checklist is a good idea. We could have a public one using github's project board
16:21:58 <ErCiccione[m]> or anything else really. But all of us are already on github
16:22:17 <sarang> Yeah... I like the idea of a checklist, and the release doesn't happen until the items are done
16:22:35 <sarang> This reduces the reliance on specific unwritten knowledge and could reduce the small errors that happen
16:22:48 <sarang> and when errors do happen, things can be added to the checklist so they don't happen again
16:23:31 <ErCiccione[m]> Yeah i agree.
16:24:07 <sarang> This upcoming release could be a great opportunity to try it out, since it sounds like there are few major changes and plenty of time expected for the ecosystem to prepare
16:24:53 <sarang> (ideally)
16:25:16 <moneromooo> I think pony shared it already. Not sure where it is though :D
16:26:19 <sarang> So useful!
16:26:20 <sarang> heh
16:26:37 <sarang> "Trezor support ready" and "Ledger support ready" should go on it
16:26:38 <sarang> :D
16:26:49 <sarang> I haven't heard back about Ledger yet
16:40:40 <ErCiccione[m]> I don't think hardware wallets should be blockers for a release. I mean, it's their duty to keep up, we shouldn't be stuck because one of them is not ready to upgrade. I agree hardware support is important, but  what happens when many hardware wallets will support Monero? We wait until all of them are ready before releasing?
16:41:09 <ErCiccione[m]> That could create a situation where companies just get lazy because "we are waiting for them anyway"
16:43:05 <ErCiccione[m]> I agree it's important to have hardware support along with a network upgrade and we should do everything we can to make that happen, but i don't think we should wait for them to be ready. Should be the other way round
16:43:07 <sarang> Sure, but a best-effort approach with adequate time is important for users
16:43:17 <sarang> If it doesn't happen (for whatever reason), users get screwed over
16:43:42 <sarang> With CLSAG, having code ready in advance and communicating with the teams has been very useful and productive
16:43:57 <ErCiccione[m]> yeah i agree with that, and users will know they should probablyh choose a different hw who can keep up with network upgrades
16:43:58 <sarang> But I see about not letting that be a blocker if there's no action
16:44:16 <sarang> At the very least, giving plenty of time acknowledges that those teams have different development workflows and timelines
16:44:29 <sarang> "We set the block height; you have a week to release firmware" is no good
16:44:43 <sarang> as an extreme example, that is
16:44:50 <ErCiccione[m]> yeah, absolutely
16:45:19 <sarang> Maybe a useful part of the checklist is assigning roles specifically
16:45:39 <sarang> e.g. for this release, sarang is assigned the role of planning and communication with hardware wallet teams
16:45:52 <sarang> This could help avoid the "nobody did it" problem
16:46:16 <ErCiccione[m]> yeah. That should be probably the case for everything else
16:46:33 <ErCiccione[m]> somebody write release notes, somebody send the email in the mailing lists, etc
16:46:35 <sarang> for sure
16:46:44 <sarang> Avoid the bystander problem
16:47:05 <sarang> At meetings, there's a specific list of what's to be done, and who is in charge of doing it (or assigning elsewhere)
16:47:51 <sarang> It seems like a reasonable balance of ensuring things get done, without causing unnecessary red tape
16:48:10 <selsta> 18:41 <ErCiccione[m]> That could create a situation where companies just get lazy because "we are waiting for them anyway" <-- what is the other solution? do a new release every time?
16:48:23 <selsta> realistically we have to wait for them to avoid doing multiple releases
16:49:48 <ErCiccione[m]> No. What i mean is that they should have plenty of time and there should be a lot of communication, but we shouldn't depend on them.
16:50:44 <ErCiccione[m]> as i said now it's two companies, but in the future will be more and IMO waiting for everybody to be prepared is not feasible
16:52:11 <sarang> Having a more established and regular process could help this... if a company knows that they need to do steps XYZ prior to a release (with good communication), then they know that failure to do so means the network could leave them behind
16:54:16 <sarang> On that note... any other thoughts on when this upgrade should (roughly) be planned for?
16:55:06 <sarang> There doesn't seem to be any need to rush things, except for the cost of less efficient transactions in the meantime
16:55:06 <ErCiccione[m]> maybe we could have a dev meeting to discuss that? the last one was some time ago.
16:55:12 <sarang> I would think so
16:56:27 <ErCiccione[m]> sunday 19?
16:56:49 <ErCiccione[m]> people in the channel what about a meeting? ^
16:56:52 <sarang> I'm down for that
16:57:14 <sarang> As long as there's a specific agenda of items to discuss and figure out
16:58:22 <ErCiccione[m]> yeah. Point one Network upgrade date and what needs to go in. Point 2 write down a checklist. Point 3 CLSAG audit status and general status?
16:58:25 <ErCiccione[m]> point 4?
16:59:06 <sarang> Meta repo issue!
16:59:19 <sarang> I use them for all MRL meetings, even though it's a standing agenda
16:59:25 <sarang> (good for log posting too)
16:59:43 <ErCiccione[m]> I think that agenda would be enough btw. I would make a meeting even just to decide an official date for the HF
16:59:48 <sarang> Point 4. Blockers and their status
16:59:56 <ErCiccione[m]> yeah i'm gonna make one now
17:00:01 <sarang> e.g. we know where Trezor is already
17:00:05 <sarang> waiting for Ledger info
17:00:36 <sarang> FWIW there's already Ledger-specific code in the CLSAG branch, but I don't know what needs to be done for their firmware, how much lead time they need after setting block height, testnet requirements, etc.
17:00:42 <ErCiccione[m]> wait, before i make the issue let's see if other people are ok with a meeting on July 19th
17:00:42 <sarang> I presume they'll want as much testnet time as possible
17:00:49 <sarang> roger
17:02:23 <sarang> ping hyc selsta moneromooo etc.
17:03:12 <selsta> so meeting next sunday? ok
17:03:54 <sarang> Oh, was the intent next Sunday or tomorrow Sunday ErCiccione[m]?
17:04:06 <sarang> e.g. 12 July or 19 July
17:04:13 <sarang> s/e.g./i.e./
17:04:21 <moneromooo> Sure.
17:04:48 <ErCiccione[m]> next sunday (19th). I guessed people would want to know about it a bit in advance
17:04:56 <sarang> sure
17:09:45 <ErCiccione[m]> usual time 17 UTC ok for everybody?
17:10:24 <sarang> sure
17:10:30 <sarang> that time seems to work for many people
17:12:00 <sarang> meta issue?
17:12:53 <ErCiccione[m]> yeah i'm writing it right now
17:13:07 <sarang> :D
17:28:11 <ErCiccione[m]> https://github.com/monero-project/meta/issues/485
17:28:18 <ErCiccione[m]> sarang ^
17:28:31 <ErCiccione[m]> feel free to suggest edits and items
17:28:46 <sarang> Thanks