10:13:20 <Snipa> .merges
10:13:20 -xmr-pr- #6489 #6497 #6500 #6501 #6509 #6512 #6516 #6526 #6529 #6534 #6536 #6537 #6538 #6542 #6546 #6557 #6565 #6571 #6578 #6580 #6586 #6593
10:43:36 <Snipa> .merges
10:43:37 -xmr-pr- #6500 #6509 #6512 #6516 #6526 #6529 #6534 #6536 #6537 #6538 #6542 #6546 #6557 #6565 #6571 #6578 #6580 #6586 #6593
10:44:00 <Snipa> Should update in a bit, a fair few of what's left needs second reviews by qualified persons. :)
10:48:31 <ErCiccione[m]> I opened an issue on the Tails repo asking to include Monero. They don't use third party repos, so they won't use whonix' repo. They seem to be willing to add it
10:48:56 <ErCiccione[m]> but reproducible builds aside i doubt the GUI will ever make it to Debian stable (now, buster)
10:48:59 <ErCiccione[m]> https://gitlab.tails.boum.org/tails/tails/-/issues/17823
10:49:57 <ErCiccione[m]> ^ that's the issue
10:50:02 <ErCiccione[m]> i don't see a quick solution. Feel free to post on that issue, obviously
11:18:30 <hyc> if we get reproducible builds for the GUI, why wouldn't debian take it?
11:22:48 <asymptotically> hyc: monero needs updates faster than their release cycle can take
11:23:59 <asymptotically> i think that was the reason given for why monero cli is still stuck in experimental or sid
11:29:42 <hyc> makes sense
11:30:04 <hyc> which ultimately tells me we shouldn't bother getting into distro repos
11:30:23 <hyc> and only provide our own 3rd party repos that users can add if they want package management
11:30:43 <hyc> ... which I think is a waste of time, especially since we have auto-updaters for our binaries now
11:35:14 <ErCiccione[m]> I think debian is the exception in this case. I'm not aware of other distros with such tight release process.
11:37:04 <ErCiccione[m]> In general i agree we shouldn't bother, but debian is a bade for many distros and having the GUI on debian stable would open a lot of doors, but yeah, not really doable at the moment.
11:38:49 <ErCiccione[m]> Btw even bitcoin is not in stable iirc.
12:51:43 <moneromooo> .merges
12:51:44 -xmr-pr- #6500 #6536 #6538 #6542 #6546 #6565 #6571 #6593
13:45:38 -xmr-pr- Parckwart opened issue #6713: Faulty behaviour with monero-wallet-cli in certain terminal emulators
13:45:38 -xmr-pr- > https://github.com/monero-project/monero/issues/6713
15:13:23 <sarang> hyc ErCiccione[m]: is there a good advantage to maintaining a third-party repo separately for debian, rather than the updater?
15:13:34 <sarang> Consistent process, clean uninstall, etc.?
16:22:00 <ErCiccione[m]> Sarang: beside the fact that debian stable users would be able to install the GUI simply using "apt install monero", would make easier for all debian-based OS to integrate the wallet.
16:22:39 <ErCiccione[m]> Whonix uses third party repos maintained by them, Tail relys on packages already in stable
16:23:12 <ErCiccione[m]> Not too much a big deal, but i would really like to have monero integrated by default in tails
16:45:38 -xmr-pr- maogo opened issue #6714:  error: can't bind socket: Permission denied. for 0.0.0.0
16:45:38 -xmr-pr- > https://github.com/monero-project/monero/issues/6714
16:49:35 <ErCiccione[m]> Meeting here in 10 minutes
17:00:14 <ErCiccione[m]> Ok everybody let's start this meeting. This is an important one since we should decide the date for the upcoming network upgrade and what consensus changes should be included. The agenda is here: https://github.com/monero-project/meta/issues/485
17:00:38 <ErCiccione[m]> Let's have a round of greetings to get an idea of who is here
17:00:41 <SerHack> Hi
17:00:43 <sgp_> Hello
17:00:44 <ErCiccione[m]> Hi everybody
17:00:54 <sarang> Hello
17:01:01 <Snipa> Good morning.
17:01:20 <sethsimmons> Hi all :)
17:01:30 <rbrunner> Grüezi
17:02:15 <ErCiccione[m]> So the main point is to decide what are we going to include in the next release, but before that, would be great to have an overview of the status of CLSAG and related audits.
17:02:29 <ErCiccione[m]> Sarang, go ahead please
17:02:36 <ErCiccione[m]> :)
17:02:38 <sarang> Sure
17:02:52 <sarang> JP and Antony (the reviewers) have completed their audit of the preprint and code
17:03:11 <sarang> They're finalizing the report for public release
17:03:22 <sarang> The preprint has already been updated, and the code does not require any security updates
17:03:38 <sarang> moneromooo is in the process of rebasing the code
17:04:05 <sarang> I've been in contact with folks on the Ledger and Trezor teams throughout the process, since they have their own development and release timelines
17:04:08 <moneromooo> in the process of preparing to get ready to start rebasing the code
17:04:17 <sarang> :)
17:04:52 <ErCiccione[m]> What's the ETA for having it PRd and ready for final reviews?
17:04:57 <sarang> Trezor is pretty much ready to go; they'll need the fork height and can then update firmware, but the Monero-specific development is done
17:05:16 <sarang> Ledger has done most of the work already and has code ready for integration on their side, but it hasn't been completed yet
17:05:47 <sarang> The person I've been working with (Francois) said the team that does the firmware integrations does _not_ have this on their 2-month timeline for some reason
17:06:32 <sarang> and that Francois would not be able to do the integration until after September 21 due to scheduling
17:07:12 <sarang> They're check to see if the Ledger integration team can prioritize this if needed
17:07:57 <sarang> Further, they want a couple of weeks to test after the integration is complete
17:08:08 <sarang> and then can set the fork height and release on whatever timeline they choose
17:08:43 <sarang> Is there a general opinion of when the upgrade should be, ideally?
17:10:18 <rbrunner> Personally I don't see much more argument than "Why wait with improvements" ...
17:11:12 <sarang> It seems like Ledger is the biggest unknown right now
17:11:28 <sgp_> Annoying that Ledger can't do any work for 2 months
17:11:34 <sethsimmons> I'm all for pushing this ASAP once code is ready to go, but if Ledger is #soon we could wait for that.
17:11:40 <sarang> Francois asked for 4 weeks between release and the upgrade height, presumably for prioritizing testing
17:11:41 <ErCiccione[m]> I guess ledger will have to adapt their schedule.
17:11:43 <sethsimmons> <sgp_ "Annoying that Ledger can't do an"> Yeah no kidding...
17:11:50 <rbrunner> "on whatever timeline they choose" sounds a little, well, harsh
17:12:02 <sarang> but they are unavailable until September 21 to do the rebase and integration
17:12:08 <ErCiccione[m]> Sarang: that's a good idea reguardless and we usually do it afaik
17:12:31 <sarang> rbrunner: I didn't mean that to sound harsh
17:12:39 <sethsimmons> Do we have a "release checklist" for this including these items?
17:12:42 <sarang> I just meant that I don't know what's required for their releases
17:12:49 <rbrunner> Alright :)
17:13:16 <ErCiccione[m]> sethsimmons: the checklist is something good to have. We can discuss that once we have a date :)
17:13:34 <sethsimmons> Ok, I'll start capturing some items for it to circle back to later.
17:13:48 <ArticMine> So we are looking realistically at the end of October?
17:14:12 <sarang> If the Ledger timeline works as I understand it from Francois, it sounds like end of October would be the soonest they could support
17:14:31 <sarang> but it's unclear if that's guaranteed to work for the Ledger team
17:14:56 <sethsimmons> What can we do to get a clearer timeline for them?
17:14:58 <rbrunner> We all on ourselves could do this probably a month earlier, right?
17:15:15 <sgp_> 3 months of notice is extremely generous time
17:15:31 <sarang> sethsimmons: I'm not sure
17:15:44 <sarang> Francois is reaching out to the coin integration team to get a better sense of their prioritization
17:15:53 <sarang> I haven't heard back about this yet
17:15:59 <ErCiccione[m]> It is extremely generous. I wouldn't go beyond three months
17:16:13 <sarang> But part of this seems to be that Francois is not available to do the necessary rebase until after Sep 21 for other reasons
17:16:30 <sethsimmons> And there isn't anyone else at Ledger that can do it?
17:16:42 <sarang> I do not know
17:17:02 <sarang> Someone else previously worked on Monero support with Ledger, but recently passed this on to Francoid
17:17:05 <sarang> *Francois
17:17:11 <sethsimmons> Ah, yes, forgot about that.
17:17:20 <sgp_> What about tentatively saying Oct 1?
17:18:14 <ErCiccione[m]> Sounds good to me
17:18:18 <sarang> I don't think that works
17:18:30 <rbrunner> Maybe depends on Ledger's reaction to that.
17:18:35 <dEBRUYNE> Seems too early
17:18:43 <dEBRUYNE> We also have to account for other wallet providers such as MyMonero
17:18:45 <ArticMine> I would suggest October 31
17:18:55 <UkoeHB_> Spooky
17:19:10 <sarang> If Francois can start the integration right away on Sep 21 and Ledger prioritizes it on their timeline, they'd still want a couple of weeks to test their release with updated Monero code before releasing firmware with the block height
17:19:19 <ErCiccione[m]> I wouldn't base the timeline on ledger's needs. We are giving them planty of time to adapt
17:19:44 <sarang> I agree that at some point the release needs to happen, but I hope there can be as much support as is possible in a reasonable timeline
17:19:51 <dEBRUYNE> I am all for allotting time for third-party wallets etc., but due to Ledger we're basically frozen for 2 months
17:19:52 <ErCiccione[m]> They are a company that makes money on Monero. They ahould adapt on us, not the other way round
17:20:10 <ErCiccione[m]> *should
17:20:34 <rbrunner> I tend to agree. If some entity cannot live with 3 months of advance warning, well, tough.
17:20:36 <ErCiccione[m]> Giving plenty of time is fine. Adapting to their priorities is not
17:21:00 <rbrunner> That's half of our "old" hardfork schedule, after all
17:21:10 <UkoeHB_> There have also been months of advance warning. The code was written a while ago
17:21:24 <sarang> Well, they were also presumably waiting to know of any changes
17:21:25 <ErCiccione[m]> Thanks for the thumbs up on matrix but those don't show up on IRC, please write what's in your mind :)
17:21:40 <sarang> I know that Francois was unavailable to join this meeting today (but said they would read the logs later), but I can present the October 31 and get their thoughts
17:21:55 <sgp_> I still would rather present Oct 1
17:21:59 <sethsimmons> As much as leaving Ledger users out to dry sucks (that includes me), if we give 3m and thats not enough with a lot of extra runway before now I'm not sure thats something we can wait even longer for.
17:22:10 <sarang> Perhaps someone else can do the necessary rebase
17:22:13 <sgp_> Oct 31 is the absolute latest and is very non-ideal
17:22:22 <sethsimmons> Yeah I'd love to hear if anyone else at Ledger can step in
17:22:30 <sarang> They made it sound like rebase and working with Ledger integration team was all that was left to do
17:22:31 <sethsimmons> 2mo without a way to rebase is.. odd
17:22:34 <ErCiccione[m]> I tend to agree woth sgp
17:22:41 <ArticMine> I would make October 31 firm, or maybe something like Oct 20
17:22:48 <ArticMine> but make it firm
17:22:52 <sarang> OK, so working backward from there
17:23:01 <sarang> October 1 is the ideal _fork height_?
17:23:04 <sarang> Not release
17:23:08 <sgp_> Coffee Chat planned on Oct 17. We can make another update edition
17:23:41 <ErCiccione[m]> Oct 17 sounds like a good compromise.
17:23:57 <ArticMine> Yes that seems reasonable
17:24:01 <sethsimmons> That gives them 3+ weeks to rebase/test after their 9/21 date
17:24:08 <sethsimmons> Hopefully that is plenty.
17:24:13 <sarang> So I'd like to know what the proposed dates would be for (a) setting the block height, (b) releasing code, (c) the upgrade height occurring
17:24:34 <sgp_> b) Sept 17
17:24:35 <sarang> Of course, once the Monero code is rebased, they can build and test on a private testnet as they wish
17:24:37 <ErCiccione[m]> Block height 17 oct release one month before?
17:25:13 <dEBRUYNE> sethsimmons: We need a release at least a few weeks in advance of the height
17:25:15 <sgp_> There will need to be another release for Ledger but that's only impactful to Ledger users, not consensus
17:25:17 <dEBRUYNE> Preferably a month or so
17:25:27 <sethsimmons> For sure
17:25:35 <sarang> Note that there's already Ledger-specific code in the current Monero CLSAG branch
17:25:38 <rbrunner> Yes, that would speak for a September 17 release, right?
17:25:42 <ErCiccione[m]> Release 17 sept, hard fork 17 october?
17:26:11 <ErCiccione[m]> Are people ok with that?
17:26:12 <kinghat[m]> does monero have a list of commandments? 11. thou shalt not hold releases for outside entities.
17:26:13 <ArticMine> That makes sense
17:26:14 <kinghat[m]> amen
17:26:31 <rbrunner> And maybe merged our changes into master on August 17? With time to play around on Testnet
17:26:35 <sarang> OK, so when would the height be finalized?
17:26:45 <sarang> Since that needs to go into their dev cycle
17:27:09 <sarang> (this is where a release checklist would be _very_ helpful...)
17:27:09 <ErCiccione[m]> I guess even now if we have a date for the hf.
17:27:25 <sethsimmons> <sarang "(this is where a release checkli"> I'm compiling a starter as we speak :)
17:27:38 <rbrunner> Seems so, the hardfork height should the be least problem if we have a date :)
17:27:52 <sarang> rbrunner: right, but it needs to happen :D
17:27:58 <sethsimmons> It could vary slightly in timing depending on HR changes, but we could set it now
17:28:25 <sarang> sethsimmons: block times are pretty consistent overall
17:28:43 <sethsimmons> Generally, yes, I wouldn't expect much variance.
17:29:12 <sgp_> Why not pick the exact height shortly before the Sept ~17 release
17:29:24 <sgp_> We did the important part of choosing the date today
17:29:28 <ErCiccione[m]> Does anybody have anything against 17 september release, 17 october hard fork? Otherwise we can officialize it as decided
17:29:40 <sethsimmons> Sounds good to me.
17:29:41 <sarang> OK, so to recap... the intent is to merge all changes by August 17 for testnet, release on September 17, and fork on October 17?
17:29:43 <ArticMine> The release need to have the fork hard coded?
17:30:14 <rbrunner> I think it better has it, yes
17:30:16 <sgp_> Yeah
17:30:34 <sarang> moneromooo: since you're getting all the CLSAG stuff rebased and updated, does that sound reasonable?
17:31:49 <moneromooo> I can do it in time yes.
17:32:03 <sarang> I'll reach out to Francois again with this timeline and see what the Ledger team can prioritize
17:32:15 <sarang> and will reach out to the Trezor team too
17:32:28 <sarang> Trezor basically said "let us know when your code is done and the height is set, and we're good"
17:33:12 <ErCiccione[m]> Nice. Let's keep going then
17:33:20 <sgp_> Trezor sounds awesome haha
17:33:23 <ErCiccione[m]> What other consensus changes do we want in?
17:33:34 <rbrunner> Are there any waiting?
17:33:57 <sethsimmons> Only potential one is BP+, correct?
17:34:01 <sgp_> There were a few more things included in the logs I posted in the meeting issue
17:34:08 <ArticMine> and issue 70 in MRL
17:34:24 <sgp_> Coinbase rings is one I'm pushing for
17:34:36 <moneromooo> I want to straightn out some unlock time stuff, technically a consensus change, but no functional change.
17:34:47 <moneromooo> I've been meaning to do that for a long while.
17:34:55 <sarang> If the freeze deadline is mid-August, I doubt BP+ could safely make it in
17:34:56 <sgp_> moneromooo: sounds good to me :)
17:34:57 <sethsimmons> <sgp_ "Coinbase rings is one I'm pushin"> What is needed for that?
17:35:13 <sarang> but TBH the size savings aren't so significant as to make that a huge loss
17:35:23 <sethsimmons> AKA could coinbase rings easily make it in in time?
17:35:30 <sgp_> BP+ would also need more review/audit right?
17:35:32 <sethsimmons> <sarang "but TBH the size savings aren't "> Yeah no need to rush that at all.
17:35:53 <sarang> sgp_: I personally think so, but part of it depends on what the actual diffs from the current code end up being
17:36:18 <sgp_> So no BP+ then
17:36:23 <sarang> When I brought up BP+ earlier (when the preprint came out), the reaction seemed quite "meh"
17:36:33 <sarang> and only now seems to have come up again with the new CCS
17:36:54 <sarang> But no, I would not plan on BP+ for the fall upgrade
17:37:01 <sarang> and certainly don't block for it
17:37:02 <ArticMine> How big are the savings?
17:37:23 <sarang> Something like 90 bytes per single proof
17:37:31 <sarang> Not massive, but not trivial either
17:38:03 <ErCiccione[m]> Ok, so seems that consensus is to keep bp+ out for now.
17:38:33 <ErCiccione[m]> What abut coinbase rings? Do we need more discussion about that?
17:38:43 <sgp_> For coinbase-only rings, luigi supports reducing the coinbase ringsize to only 1
17:38:56 <sethsimmons> I'm still not sure whats still needed for that/how feasible it is to make it into the HF
17:39:04 <sethsimmons> sgp_: can you speak to that?
17:39:17 <sethsimmons> I'm for the change overall, just not sure on details
17:39:22 <sgp_> I can't speak to moo and others' ability to code it in time
17:40:45 <sethsimmons> moneromooo: any idea on timelines for that/is anyone else helping with coding that?
17:41:26 <moneromooo> Nobody is doing this AFAIK. I won't unless MRL clearly says it should be done.
17:42:09 <moneromooo> In which case it's an easy change I think.
17:42:17 <rbrunner> Yeah, reading the IRC notes on the meta issue I was wondering whether there is already our famous "loose consensus" about this, or quite diverging opinions
17:42:23 <sethsimmons> sarang: any feedback on that overall?
17:42:27 <sethsimmons> I've seen back and forth but no clear decision.
17:42:40 <rbrunner> After all it's again some step up in protocol complexity.
17:42:46 <ErCiccione[m]> rbrunner: my feeling too
17:43:18 <ArticMine> I see the question being consensus rather than coding time
17:43:37 <sethsimmons> Appears so :)
17:43:41 <sarang> I marginally support such a change, but it would require pretty hefty testing
17:44:01 <sarang> Since it would affect how outputs are selected in the distribution
17:44:16 <sgp_> This doesn't require a consensus change, but it's related to https://github.com/monero-project/monero/issues/5222
17:45:16 <sethsimmons> coinbase rings requires consensus change, correct?
17:45:52 <sgp_> Yeah
17:46:07 <moneromooo> Yes, if you want nodes to reject those that don't behave.
17:46:23 <sethsimmons> Figured, just wanted to make sure.
17:46:46 <sethsimmons> The main reason I'd like to see it in this upgrade (if we can reach rough consensus) is because its not worth its own HF so would have to wait for another down the line
17:46:50 <sethsimmons> Which could be a while.
17:47:02 <sethsimmons> Would it be worthwhile to separate out a meeting for that discussion?
17:47:10 <sarang> sethsimmons: for which proposal exactly?
17:47:16 <sarang> (too many things flying back and forth)
17:47:20 <sethsimmons> coinbase ring changes
17:47:22 <sethsimmons> SOrry :)
17:48:01 <ErCiccione[m]> I would say let's wait for clear consensus before deciding  about coinbase rings in the october hard fork. It's not super urgent anyway and we don't have to decide now.
17:48:13 <sarang> Rushing output selection changes seems unwise
17:48:23 <sarang> but that's not a reason not to do them if desired, of course
17:48:55 <rbrunner> Well, if we want to be able to play with the release on Testnet in 1 month, that's not much time left.
17:49:23 <sethsimmons> True, especially since it seems to need a good bit of testing/verification even after code release
17:49:28 <hyc> you can always setup private testnets
17:49:34 <sarang> The CLSAG changes are significant enough that I think delaying for smaller changes is not worth it
17:49:55 <sarang> Having plenty of time to test CLSAG will be important
17:50:11 <sethsimmons> Definitely agree.
17:50:17 <sgp_> I don't think this would cause a delay; rather no one else seems enthusiastic about it
17:50:49 <sethsimmons> I'm enthusiastic about it :P But there certainly doesn't seem to be strong consensus
17:51:18 <rbrunner> I would rather wait a little and wait for 50+ rings, with Triptych, making some such problems marginal as I see it
17:51:39 <hyc> no clear benefit, nobody knows what the risks actually are. sounds like a bad idea
17:52:07 <sethsimmons> Hmm, hadn't thought about what effect increased ringsizes would have on it in future.
17:52:47 <sgp_> The problem stays and scales, but the convincing ringsize is still larger
17:53:15 <ErCiccione[m]> Alright. I think the general feeling is to not include coinbase rings in the upcoming release. Let's not go in depth about it now, it can be discussed in another meeting :)
17:53:32 <sgp_> Sure, no one else really cares so pass
17:53:49 <ErCiccione[m]> Anything else that we want in? Or any blockers that should be resolved?
17:53:56 <rbrunner> Well, not care sounds harsh, just different weighting of trade-offs maybe
17:54:20 <sarang> sgp_: I do care, and would support a change if implemented and tested carefully
17:54:39 <sarang> I think it's somewhat marginal for heuristics, as I've said elsewhere
17:55:16 <ErCiccione[m]> As far as i understood there shouldn't be blockers, right? The biggest issue right now seems to be ledger that cpuld be late
17:55:48 <sarang> Right, it's not clear when the Ledger release would be available
17:56:10 <rbrunner> Let's see what they come up if a little gentle pressure
17:56:25 <sarang> Yeah, now that there's a date in mind, I'll let them know and see what could be done
17:56:26 <rbrunner> Of an October 17 hardfork
17:56:32 <sarang> Perhaps they hadn't prioritized because no date was known
17:56:37 <sarang> which is understandable
17:56:58 <sarang> And if there are useful coinbase changes and/or BP+, that would make for a nice subsequent release at some point
17:57:15 <sethsimmons> Good point on the subsequent release :)
17:57:34 <rbrunner> So we won't run out of hardforks anytime soon :)
17:57:48 <sethsimmons> Gotta keep the FUD alive :D
17:58:19 <ErCiccione[m]> Alright. So, let's start talking about splitting duties. Wpuld be good to have a checklist of stuff that needs to be done and people willing to take care of it
17:58:31 <sarang> Yeah, a while back I brought up the idea of a checklist
17:58:38 <ErCiccione[m]> We don't necessarely have to decide everything now, but wpuld be good to start
17:58:44 <sarang> Where assignments can be made for who is responsible, and when, etc.
17:58:47 <sethsimmons> <ErCiccione[m] "Alright. So, let's start talking"> I have a WIP checklist I can share if you'd like.
17:58:56 <sarang> and hopefully avoid a lot of the small errors and problems that happen from time to time
17:59:05 <sarang> e.g. "the hashes don't match" etc.
17:59:08 <sethsimmons> And I'm happy to own some of the administrative tasks (contacting entities, etc.)
17:59:13 <rbrunner> Didn't fluffypony hand over something a while ago?
17:59:13 <ErCiccione[m]> sethsimmons: yes please we can then integrate it with some that are already around (fluffypony has one)
17:59:23 <sarang> rbrunner: he had a few things, yes
17:59:40 <sarang> Having an ongoing list would be great, and any issues that arise can be added to avoid in future releases
17:59:53 <sethsimmons> Let me post to a pastebin site
17:59:59 <sethsimmons> Copy paste will end poorly for you IRCers
18:00:05 <sarang> yeahhhhh
18:00:23 <sethsimmons> https://paste.centos.org/view/84f18a65
18:00:25 <sethsimmons> Initial list
18:00:28 <sethsimmons> Very WIP
18:00:33 <hyc> hmmm. Can post an instance of the checklist for each release
18:00:35 <hyc> on gitlab
18:00:41 <sethsimmons> I'm sure I have some steps out of order etc
18:00:42 <hyc> and make each point an unresolved thread
18:00:47 <sethsimmons> <hyc "on gitlab"> Yeah that would be the intent
18:00:48 <hyc> and then resolve them as they are taken care of
18:00:56 <sethsimmons> Host it in an issue perhaps with MD checklist
18:01:03 <sarang> something something gantt chart
18:01:03 <sethsimmons> *meta issue
18:01:21 <rbrunner> Soon we will end up on JIRA
18:01:29 <sethsimmons> I'm a JIRA admin dont tempt me
18:01:33 <hyc> JIRA - where software projects go to die
18:01:37 <sethsimmons> :P
18:01:38 <sarang> GitHub supports basic kanban boards
18:02:19 <ErCiccione[m]> I would say a basic kanban on github would do it. We could link issues to it and assign issues to prople
18:02:24 <sethsimmons> Should I open a meta issue to work through the creation of the checklist?
18:02:34 <sethsimmons> So we can have discussion/updates/etc.
18:02:42 <rbrunner> Sounds good
18:03:16 <sarang> Ah, a checklist checklist
18:03:21 <sethsimmons> XD
18:03:25 <sethsimmons> We've gone too deep
18:03:34 <ErCiccione[m]> Lol, but i do think would be useful
18:04:37 <sethsimmons> Any initial feedback on the first stab at the list?
18:04:38 <sgp_> I have a self-hosted Wekan available (Trello clone)
18:04:48 <sethsimmons> If not I'll open the issue now and we can iterate as needed.
18:05:07 <sarang> Ledger/Trezor coding is a bit more abstract
18:05:24 <sarang> Unless you mean "on the Monero codebase"
18:05:26 <ErCiccione[m]> sgp_: i would keep it simple and just create one on github. Also much more visible
18:05:33 <sarang> e.g. there's Ledger-specific code in Monero
18:05:37 <sarang> as a device option
18:05:55 <sethsimmons> I'll break that into our end and their end
18:07:32 * sethsimmons sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/ioQposdWvgLsHrglHKedyYMn >
18:07:43 <sethsimmons> Oof that didn't paste well
18:08:01 <sethsimmons> https://paste.centos.org/view/29c74c53 <- Better?
18:08:28 <sarang> Wallets should be informed as early as possible IMO
18:08:46 <sarang> As should exchanges
18:08:53 <sethsimmons> Right after fork height, or tagging?
18:09:08 <sarang> Seems that exchanges operate at the speed of a glacier as it is
18:09:26 <sarang> I'd say right at fork height, so they can plan for it
18:09:45 <sethsimmons> done.
18:09:49 <sarang> Even if they don't start working right away, then they at least know when to expect the release and the upgrade
18:09:59 <sethsimmons> Any last updates? Don't wanna derail this meeting too much with the first take on it.
18:10:09 <ErCiccione[m]> Alright. I would say we can conclude the meeting
18:10:29 <ErCiccione[m]> The discussion about the checklist can continue after or directly on the meta issue
18:10:31 <sarang> OK, what are action items on this?
18:10:40 <sarang> I'm going to contact Trezor and Ledger folks ASAP with these dates
18:10:54 <ErCiccione[m]> Nope, we are done.
18:11:12 <ErCiccione[m]> Thanks everybody for participating. You are free to go back to your sundays :)
18:11:33 <sethsimmons> Thanks all, and thanks for running this ErCiccione!
18:12:13 <sarang> thanks all
18:12:18 <ArticMine> Thanks
18:14:23 <sethsimmons> Initial upgrade checklist and meta issue: https://github.com/monero-project/meta/issues/489
18:16:10 <tevador> there is another open discussion about removing the tx_extra field, although it's probably not relevant for the next release (issue #6668)
18:17:06 <sarang> indeed tevador
18:18:45 <hyc> Basically tx_extra allows us to augment the tx format without changing the tx version
18:19:08 <sarang> Isn't that benefit somewhat negated by the use of semiregular network upgrades anyway?
18:19:21 <hyc> seems like that's a pointless feature to have
18:23:02 <sarang> Moving transaction elements out of extra means lowering the possibility for fingerprinting transactions based on non-enforced structure
18:24:55 <tevador> the general consensus was in favor of removing tx_extra
18:30:40 <ErCiccione[m]> I we want to remove it out we should really make it known soon, to make sure we are not breaking anybody's setup imho.
18:42:12 <dEBRUYNE> *If* we want to remove it, we can announce it soon and then actually remove it in the next upgrade I guess (the one after CLSAG)
18:42:21 <dEBRUYNE> That should allot plenty of time to make necessary changes
18:51:42 <UkoeHB_> I am somewhat against remove the extra field, but don't have a strong opinion
18:52:51 <fluffypony> rbrunner: fwiw my Release Engineering list was focused on getting a release out there
18:53:02 <fluffypony> not on hard fork duties
18:53:41 <fluffypony> dEBRUYNE used to do a lot of groundwork around hard forks, he might have further thoughts on what to include in RE lists for hard forks
18:58:49 <sethsimmons> Would you mind sharing your list so I can compare/combine?
18:58:58 <sethsimmons> Or do you think we should keep them separate?
18:59:04 <sethsimmons> fluffypony: ^^
18:59:16 <fluffypony> oh
18:59:20 <fluffypony> sorry I thought someone had shared it
18:59:21 <fluffypony> one sec
19:01:17 <fluffypony> sethsimmons: https://paste.centos.org/view/raw/0f0e3b00
19:02:16 <sethsimmons> Thanks!
19:04:47 <sethsimmons> I'll probably leave the specifics around code updates out of this, but have added the specifics on updating downloads/hashes
19:05:47 <sethsimmons> Hmm, they should probably be captured somewhere, though... I'll give it some thought.
19:18:52 <fluffypony> yeah everything's kinda intertwined
19:19:23 <fluffypony> also FYI web.getmonero.org is the CDN, the source is just getmonero.org
19:19:30 <fluffypony> no wait other way around
19:19:34 <fluffypony> lol
19:19:45 <fluffypony> so leave it as is
19:19:59 <sethsimmons> 😅 glad I’m not the only one that confuses
19:22:52 <sarang> Wouldn't necessarily need to _remove_ extra (but it's probably optimal for fingerprint reduction)
19:23:00 <sarang> but at least moving known tx elements out would help
19:28:04 <UkoeHB_> note this proposal also has an implementation guideline that includes removing things from extra https://github.com/monero-project/monero/issues/6456
19:30:32 <tevador> yes, removing everything non-optional from tx_extra would be a good first step
19:33:20 <dEBRUYNE> fluffypony: The gist of it was basically to spam information about the upcoming HF as wide and as much as possible
19:33:26 <dEBRUYNE> And trying to contact exchanges etc.
19:33:33 <dEBRUYNE> I guess most of it is condensed now on the mailing list (the contacts)
19:33:44 <dEBRUYNE> So a few emails on that + wide social media coverage should suffice
19:34:05 <fluffypony> tks dEBRUYNE
19:35:09 <dEBRUYNE> With a less tight schedule and no PoW changes it also becomes easier
19:35:22 <dEBRUYNE> Last time we tagged 5 weeks before the HF iirc and there was plenty of time for services to upgrade
19:35:39 <dEBRUYNE> A new software version is mostly a drop-in (barring some testing of course)
20:04:46 <fluffypony> except for wallets
20:04:52 <fluffypony> they're the ones that struggle the most
20:04:58 <fluffypony> but for exchanges and services year
20:05:01 <fluffypony> *yaeh
20:05:04 <fluffypony> *yeah
20:43:43 <dEBRUYNE> Yep
20:43:53 <dEBRUYNE> We should accomodate plenty of time for wallets with this CLSAG upgrade