10:11:33 <m-relay> <s​yntheticbird:monero.social> I think it might be beneficial to buffer hard fork preparation into a specific branch but i don't think its currently what causing all the stability fuss for release. It's feature changes (and now known but at the time unknown vuln fix) PRs that introduced regression only discovered during testing prior to release, especially the Windows version. Either release frequency is increa<clipped message>
10:11:34 <m-relay> <s​yntheticbird:monero.social> sed with a hardcap so that people are testing all versions every N months, or we keep planned release every 6 months but do some testing every say 2 months.
10:19:46 <selsta> from what I remember this release all PRs that introduced regressions were vulnerability fixes or bug fixes
10:20:09 <m-relay> <s​yntheticbird:monero.social> Yes
10:21:10 <m-relay> <s​yntheticbird:monero.social> Only one that wasn't a vuln fix and that caused regression was the windows ntfs compression detection PR
10:22:02 <selsta> yep but i would classify that PR as a bug fix since monerod crashing when compression is enabled is not intended behavior
10:22:15 <m-relay> <o​frnxmr:xmr.mx> I almost forgot about nuking the db on windows :)
10:23:49 <m-relay> <s​yntheticbird:monero.social> Since there are no layout that are thrilling all of us right now, I have a few questions to narrow down what possible changes could be introduced:
10:23:50 <m-relay> <s​yntheticbird:monero.social> Do we want dependency freeze for release? We could also just be conservative on library support for master
10:23:52 <m-relay> <s​yntheticbird:monero.social> Do we want to rely on N months for feature shipping? Or do we want to think on case by case basis
10:23:54 <m-relay> <s​yntheticbird:monero.social> Also selsta, would you be favorable to buffering hard fork preparation into a hardfork branch, for keeping master strictly to features additions + bug fixes
10:24:35 <m-relay> <s​yntheticbird:monero.social> also re: features it somewhat becomes very blurry since vuln fixes are almost in all cases blended into feature additions
10:25:05 <selsta> the more branches the more PR we have to open for the different branches if something needs to be applied to all
10:25:45 <m-relay> <t​obtoht:monero.social> "We could also just be conservative on library support for master" <- We support libraries / deps on master for at least EOL + 1y, which imo is already conservative.
10:28:36 <m-relay> <s​yntheticbird:monero.social> selsta: The only additional PRs would be merging master into hardfork (if needed) and merging hardfork into master when its time to ship. If this is done on a two monthly basis I don't think it will make much PRs.
10:29:39 <m-relay> <s​yntheticbird:monero.social> tobtoht: No reason for an LTS branch then, are there any features additions to monerod so far that isn't related to PRs that haven't been introduced into both master and release?
10:29:55 <m-relay> <s​yntheticbird:monero.social> isn't related to HF*
10:30:17 <m-relay> <s​yntheticbird:monero.social> If all features end up being merged into both release branch have no purpose
10:30:44 <m-relay> <s​yntheticbird:monero.social> and its just a matter of separating HF into its own branch to avoid breaking conflict
10:41:38 <m-relay> <s​yntheticbird:monero.social> scrolling through PRs merged, I don't see a single feature addition that hasn't been put in release. Only PRs exclusive to master are: 
10:41:38 <m-relay> <s​yntheticbird:monero.social> - code cleaning
10:41:40 <m-relay> <s​yntheticbird:monero.social> - ci improvements
10:41:42 <m-relay> <s​yntheticbird:monero.social> - dns_util related
10:41:44 <m-relay> <s​yntheticbird:monero.social> - maintainers/contributors pgp key
10:41:46 <m-relay> <s​yntheticbird:monero.social> - all the PRs for preparing hard forks components
10:43:03 <m-relay> <s​yntheticbird:monero.social> We're testing both release and master at tag time. Is it really worth it to substract release branch from the four first categories of PRs and have to open two PRs at every feature addition or bug fix
10:44:17 <m-relay> <o​frnxmr:xmr.mx> there are a lot of prs on master that arent on release
10:45:02 <m-relay> <s​yntheticbird:monero.social> yeah? thats the one i listed, or are you referring to feature additions?
10:45:48 <m-relay> <o​frnxmr:xmr.mx> the socks5 stuff is an example
10:46:16 <m-relay> <s​yntheticbird:monero.social> socks5 isn't merged yet and we've asked for vtnerd to open a release branch so it is meant to be merged into both branches
10:46:53 <m-relay> <o​frnxmr:xmr.mx> its not technically supposed to be merged onto release
10:47:04 <m-relay> <o​frnxmr:xmr.mx> Same as the multi-uri stuff
10:48:00 <m-relay> <o​frnxmr:xmr.mx> we asked for it _because_ there is no timeframe to branch/tag master
10:48:26 <m-relay> <o​frnxmr:xmr.mx> And we dont want to wait for fcmp for features
10:48:45 <m-relay> <s​yntheticbird:monero.social> i see.
10:49:04 <m-relay> <s​yntheticbird:monero.social> but that reasoning is wrong imo, we shouldn't be trying to expect master timeframe since we know for a fact we can't guarantee it
10:49:14 <m-relay> <s​yntheticbird:monero.social> just ship the features anyway
10:49:16 <m-relay> <o​frnxmr:xmr.mx> same goes for subtract fee from outputs or background sync, these shouldnt have been merged on release imho
10:50:40 <m-relay> <o​frnxmr:xmr.mx> should have branched (or tagged..) from master to release them
10:51:22 <m-relay> <t​obtoht:monero.social> I propose we branch v0.19.1 from master once the latest round of PRs is in. From this point forward only bugfixes go into the release branch. We test the release branch, fix bugs and tag a release once ready. When we want to ship new features we branch v0.19.2 from master. I.e. we branch from master more often (say once every 3-6 months) and limit release branches to bugfixes only<clipped message>
10:51:24 <m-relay> <t​obtoht:monero.social> . Hardfork changes should not go into master until we are ready to cut a hardfork release.
10:52:21 <m-relay> <s​yntheticbird:monero.social> tobtoht, iirc the only purpose of release branch is for hotfix?
10:52:25 <m-relay> <s​yntheticbird:monero.social> tobtoht, iiuc the only purpose of release branch is for hotfix?
10:52:55 <m-relay> <o​frnxmr:xmr.mx> Release branch v0.19.1 or .0?
10:53:24 <m-relay> <t​obtoht:monero.social> Oop, yes. Start at 0
10:54:50 <m-relay> <0​xfffc:monero.social> kind of similar to canary -> dev -> beta -> stable branch of chrome.
10:55:19 <m-relay> <s​yntheticbird:monero.social> I'm okay with this layout as it stop the feature pseudo-difference between release and master shenanigan. also hardfork being separated is good. I'm afraid this won't please selsta tho
10:56:06 <m-relay> <s​yntheticbird:monero.social> features are shipped 3 to 6 months, breaking is kept in containment inside hardfork branch, release is there to facilitate urgent hotfixes/vuln fixes
10:56:23 <m-relay> <o​frnxmr:xmr.mx> my only issue with branching very often is having a lot of branches. And deprecating branches quickly
10:56:28 <m-relay> <0​xfffc:monero.social> I had a similar proposal. 
10:56:28 <m-relay> <0​xfffc:monero.social> 1. Canary ( everything approved goes )
10:56:30 <m-relay> <0​xfffc:monero.social> 2. Dev ( after short time frame ) . similar to feature branch in most repos.
10:56:32 <m-relay> <0​xfffc:monero.social> 3. Beta, only after extensive tests. 
10:56:34 <m-relay> <0​xfffc:monero.social> 4. Stable: Only bug fixes ( like LTS ). and only updated in hf
10:57:37 <m-relay> <0​xfffc:monero.social> Last summer, we talked about this ( release and branching issue ) extensively.
10:57:47 <m-relay> <o​frnxmr:xmr.mx> (which is the angle of my suggestion to branch yearly and tag directly in the interim)
10:58:32 <m-relay> <o​frnxmr:xmr.mx> Since we can tag as often as we like w/o deprecating the "stable" branch too often
10:59:54 <m-relay> <o​frnxmr:xmr.mx> I think the main point of contention is that we'd be releasing 2 versions at once (master branch tags and release branch tags)
11:02:52 <m-relay> <s​yntheticbird:monero.social> .
11:02:59 <m-relay> <s​yntheticbird:monero.social> We would only be releasing from release branch for hotfix
11:03:04 <m-relay> <s​yntheticbird:monero.social> we won't have two types of release
11:03:12 <m-relay> <t​obtoht:monero.social> yes
11:03:21 <m-relay> <t​obtoht:monero.social> I don't support an LTS branch, tagging master, or multiple concurrent releases. This just increases maintenance complexity and we'll run into the same problems we have now where fixes are hard to backport because of mismatching minimum library versions or c++ standard.
11:18:37 <m-relay> <g​ingeropolous:monero.social> dunno if its helpful, but the history is kinda like this. Long ago, there was a dev branch and a master branch. Dev branch became incompatible with master branch or something or other, so I think it became abandoned?. There was something being worked on in it, i forget what. People started doing the "tag master for release to create a branch" thing, and then new features would go <clipped message>
11:18:38 <m-relay> <g​ingeropolous:monero.social> in master, and bug fixes would go in the tagged release branch.  And that got written in the docs. At least this is what i remember. I remember compiling dev branch.
11:27:12 <m-relay> <t​obtoht:monero.social> A dev branch will need constant rebasing to stay in sync with master. Large features should be developed out of tree, like they are now, and submitted to master when they are ready.
11:29:25 <m-relay> <s​yntheticbird:monero.social> Not only that but you're layout just limit the duplication of PRs for both branch to bug fixes, anything else will only be one PR (feature->master) to review. not ideal but a substantial improvement.
11:30:08 <m-relay> <s​yntheticbird:monero.social> I agree with this but at the end hard fork can be considered as a large feature and it is worth having this branch on the main repo
11:31:39 <m-relay> <t​obtoht:monero.social> Bugfixes should be submitted to master and can be bundled in a 'backport' PR when we need to cut a bugfix release. Bitcoin does it like this and we have done this in the past: https://github.com/monero-project/monero/pull/7997
11:32:00 <m-relay> <o​frnxmr:xmr.mx> You dont think branching every 3 months is a mess?
11:32:49 <m-relay> <o​frnxmr:xmr.mx> I think each new branch should be a new major version (18>19>20 etc)
11:32:56 <m-relay> <t​obtoht:monero.social> Doesn't have to be on a schedule. Rather 'branch when ready'.
11:33:09 <m-relay> <s​yntheticbird:monero.social> I see
11:33:17 <m-relay> <t​obtoht:monero.social> That implies features get backported to the release branch.
11:33:40 <m-relay> <s​yntheticbird:monero.social> I would like to be on schedule to avoid a "BuT wE HaVe nO tImE frAmE foR brAnChiNg so LeTs bAckPorT mUh FeAtUrE"
11:34:18 <m-relay> <t​obtoht:monero.social> We could still target a specific time-frame. It just doesn't have to be a hard deadline.
11:34:34 <m-relay> <s​yntheticbird:monero.social> ok
11:35:11 <m-relay> <3​21bob321:monero.social> Schedule every orange moon
11:35:26 <m-relay> <o​frnxmr:xmr.mx> So does branching from 19.0>19.1 though (?)
11:36:35 <m-relay> <o​frnxmr:xmr.mx> in your proposal (tob), how often are we branching master (and dropping the prior branch)?
11:36:51 <m-relay> <t​obtoht:monero.social> 19.1 would branch from master, not 19.0
11:38:01 <m-relay> <o​frnxmr:xmr.mx> Wheres 19.0?
11:38:09 <m-relay> <o​frnxmr:xmr.mx> (unrelated but curious)
11:40:22 <m-relay> <s​yntheticbird:monero.social> So to formalize tobtoht proposal:
11:40:22 <m-relay> <s​yntheticbird:monero.social> following semantic versioning
11:40:24 <m-relay> <s​yntheticbird:monero.social> patch versions -> release branch (bug fixes only)
11:40:26 <m-relay> <s​yntheticbird:monero.social> minor versions -> master branch (features+bug fixes)
11:40:28 <m-relay> <s​yntheticbird:monero.social> major versions -> hardfork branch (which is merged into master at shipping time)
11:40:30 <m-relay> <s​yntheticbird:monero.social> Every (planned) 3 months a release branch is created with the current set of features. We delete the old release branch. We create tag a release out of this new branch. This branch is only used for maintenance/hotfix (bug fixes + vulnerability). Every PRs goes into master, if we need to backport bug fixes we cherrypick them and make a PR (backport-branch->release).
11:40:32 <m-relay> <s​yntheticbird:monero.social> hard fork PR are put in a `hardfork` (name TBD) branch that is keeping in sync with master. Once HF needs to be shipped we push hardfork into master.
11:41:06 <m-relay> <s​yntheticbird:monero.social> a release branch is created from master*
11:41:46 <m-relay> <o​frnxmr:xmr.mx> thats 4 new branches every year? And whats the point of bugfixes to release branch if the next release will likeky be cut from master in 3 months
11:41:56 <m-relay> <s​yntheticbird:monero.social> hotfix
11:42:02 <m-relay> <s​yntheticbird:monero.social> being responsible enough
11:42:03 <m-relay> <o​frnxmr:xmr.mx> Sounds like the branches are all basically single-use
11:42:08 <m-relay> <s​yntheticbird:monero.social> to ship vuln fix in less than 90 days
11:43:46 <m-relay> <t​obtoht:monero.social> e.g Say we tag v0.19.0.0. Oopsie, turns out there is a bug/vulnerability that can't wait -> we backport the fix to the v0.19.0 branch and tag v0.19.0.1.
11:43:50 <m-relay> <s​yntheticbird:monero.social> Normally the release branch will not be used, but in the case there is a vuln fix or critical bug fix to ship out we will be very happy this release branch exist and we don't have to start bisecting what feature PR from where has caused a regression
11:45:02 <m-relay> <o​frnxmr:xmr.mx> But then still cut a new branch from master in 3 months?
11:45:19 <m-relay> <s​yntheticbird:monero.social> yes
11:45:33 <m-relay> <s​yntheticbird:monero.social> not a bad tradeoff imo
11:46:03 <m-relay> <s​yntheticbird:monero.social> creating a new branch is one click. revewing two PRs and potentially bisecting a regression take at least a week+
11:48:09 <m-relay> <s​yntheticbird:monero.social> tobtoht mind making an issue so that selsta and others can formalize his thoughts on it
11:48:13 <m-relay> <s​yntheticbird:monero.social> their*
11:48:20 <m-relay> <o​frnxmr:xmr.mx> so the difference between current and proposed, is simply that we branch master / deprecate release more often
11:49:16 <m-relay> <t​obtoht:monero.social> Plus we stop backporting features to the release branch.
11:49:24 <m-relay> <s​yntheticbird:monero.social> the core change is exactly that. The consequence that will differ from now is that we never backport features + avoid the mergeathon friction
11:49:46 <m-relay> <s​yntheticbird:monero.social> there is also the hardfork branch
11:49:47 <m-relay> <o​frnxmr:xmr.mx> I think the problem here is that we'll (hypothetically) be in the same position. Where we dont branch master for reasons
11:50:38 <m-relay> <s​yntheticbird:monero.social> Less PRs frictions, easier reviews, if we manage to get late on release then it's skill issue ngl
11:50:43 <m-relay> <o​frnxmr:xmr.mx> Like "master updates a b c and we have to support x y z for another 6 months"
11:51:22 <m-relay> <o​frnxmr:xmr.mx> So a) cant branch or b) cant merge prs to master
11:51:52 <m-relay> <s​yntheticbird:monero.social> what is a b c supposed to be ?
11:51:56 <m-relay> <t​obtoht:monero.social> This wouldn't occur. Changes that break support for x y z (for as long as we support them) don't get merged into master.
11:52:20 <m-relay> <s​yntheticbird:monero.social> yeah i was going to say this would fall into either hardfork or long-living feature branch
11:52:26 <m-relay> <s​yntheticbird:monero.social> only merged when having to be shipped
11:53:49 <m-relay> <o​frnxmr:xmr.mx> Were on the same page as far as "master should be released every 3-6 months" :)
11:56:28 <m-relay> <o​frnxmr:xmr.mx> i probably just dont like the idea of creating a lot of new branches for the same major version
13:31:58 <m-relay> <s​yntheticbird:monero.social> https://github.com/monero-project/monero/issues/9912
13:37:02 <m-relay> <t​obtoht:monero.social> "no more release version of PRs" <- The only exception to this would be build system fixes, which need to be timely. (E.g. when the latest release branch doesn't build on Arch because library x got updated and introduced breaking changes.)
13:40:03 <m-relay> <s​yntheticbird:monero.social> edited
13:44:24 <m-relay> <t​obtoht:monero.social> I'm not sure if we necessarily need a hard fork branch. If we need to review it in parts, we could do that out of tree. It's unclear how and who would keep the branch "in sync with master". I don't like the idea of giving devs write access to feature branches.
13:45:25 <m-relay> <t​obtoht:monero.social> access to feature branches under monero-project/monero*
13:46:49 <m-relay> <s​yntheticbird:monero.social> It's just matter of ease of access for related contributors. Having discussion and PRs on Monero hardfork outside of monero repository seems counter-intuitive. But ultimately this doesn't change a lot, ig this will be to selsta to decide.
14:14:18 <m-relay> <t​obtoht:monero.social> To give another example from our neighbours: Bitcoin did most of the review for its Autotools -> CMake migration out of tree (https://github.com/hebasto/bitcoin/pull/18). Once ready, all changes were submitted in a single PR to master (https://github.com/bitcoin/bitcoin/pull/30454) which then prompted additional review and testing.
14:14:33 <m-relay> <t​obtoht:monero.social> This is similar to what we're doing with the fcmp++-staging branch on seraphis-migration/monero. (https://github.com/seraphis-migration/monero/pulls).
14:14:39 <m-relay> <t​obtoht:monero.social> Keeps things decluttered during the development phase. For the sake of visibility and avoid the risk of losing discussion, we could create 'monero-project/monero-hf-staging' where we give select devs write access.
14:19:10 <m-relay> <s​yntheticbird:monero.social> I understand
14:19:21 <m-relay> <s​yntheticbird:monero.social> mind adding a comment on the issue
15:01:07 <selsta> .merge+ 9911
15:01:08 <xmr-pr> Added
15:41:14 <tobtoht_> .merges
15:41:14 -xmr-pr- 9404 9859 9875 9911
15:49:29 <tobtoht_> sech1: can you sign off on 9404 or confirm your comments were addressed
15:50:21 <tobtoht_> also 9875
16:41:19 <m-relay> <s​yntheticbird:monero.social> 10000th PR when
19:31:56 <m-relay> <0​xfffc:monero.social> Anyone can take look at 9910 ?
20:09:06 <m-relay> <s​yntheticbird:monero.social> i beg two other people to just pull up his branch, and check it in an IDE
20:09:24 <m-relay> <s​yntheticbird:monero.social> also thx 0xfffc