<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>

<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.

from what I remember this release all PRs that introduced regressions were vulnerability fixes or bug fixes

<s​yntheticbird:monero.social> Yes

<s​yntheticbird:monero.social> Only one that wasn't a vuln fix and that caused regression was the windows ntfs compression detection PR

yep but i would classify that PR as a bug fix since monerod crashing when compression is enabled is not intended behavior

<o​frnxmr:xmr.mx> I almost forgot about nuking the db on windows :)

<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:

<s​yntheticbird:monero.social> Do we want dependency freeze for release? We could also just be conservative on library support for master

<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

<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

<s​yntheticbird:monero.social> also re: features it somewhat becomes very blurry since vuln fixes are almost in all cases blended into feature additions

the more branches the more PR we have to open for the different branches if something needs to be applied to all

<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.

<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.

<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?

<s​yntheticbird:monero.social> isn't related to HF*

<s​yntheticbird:monero.social> If all features end up being merged into both release branch have no purpose

<s​yntheticbird:monero.social> and its just a matter of separating HF into its own branch to avoid breaking conflict

<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:

<s​yntheticbird:monero.social> - code cleaning

<s​yntheticbird:monero.social> - ci improvements

<s​yntheticbird:monero.social> - dns_util related

<s​yntheticbird:monero.social> - maintainers/contributors pgp key

<s​yntheticbird:monero.social> - all the PRs for preparing hard forks components

<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

<o​frnxmr:xmr.mx> there are a lot of prs on master that arent on release

<s​yntheticbird:monero.social> yeah? thats the one i listed, or are you referring to feature additions?

<o​frnxmr:xmr.mx> the socks5 stuff is an example

<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

<o​frnxmr:xmr.mx> its not technically supposed to be merged onto release

<o​frnxmr:xmr.mx> Same as the multi-uri stuff

<o​frnxmr:xmr.mx> we asked for it _because_ there is no timeframe to branch/tag master

<o​frnxmr:xmr.mx> And we dont want to wait for fcmp for features

<s​yntheticbird:monero.social> i see.

<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

<s​yntheticbird:monero.social> just ship the features anyway

<o​frnxmr:xmr.mx> same goes for subtract fee from outputs or background sync, these shouldnt have been merged on release imho

<o​frnxmr:xmr.mx> should have branched (or tagged..) from master to release them

<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>

<t​obtoht:monero.social> . Hardfork changes should not go into master until we are ready to cut a hardfork release.

<s​yntheticbird:monero.social> tobtoht, iirc the only purpose of release branch is for hotfix?

<s​yntheticbird:monero.social> tobtoht, iiuc the only purpose of release branch is for hotfix?

<o​frnxmr:xmr.mx> Release branch v0.19.1 or .0?

<t​obtoht:monero.social> Oop, yes. Start at 0

<0​xfffc:monero.social> kind of similar to canary -> dev -> beta -> stable branch of chrome.

<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

<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

<o​frnxmr:xmr.mx> my only issue with branching very often is having a lot of branches. And deprecating branches quickly

<0​xfffc:monero.social> I had a similar proposal.

<0​xfffc:monero.social> 1. Canary ( everything approved goes )

<0​xfffc:monero.social> 2. Dev ( after short time frame ) . similar to feature branch in most repos.

<0​xfffc:monero.social> 3. Beta, only after extensive tests.

<0​xfffc:monero.social> 4. Stable: Only bug fixes ( like LTS ). and only updated in hf

<0​xfffc:monero.social> Last summer, we talked about this ( release and branching issue ) extensively.

<o​frnxmr:xmr.mx> (which is the angle of my suggestion to branch yearly and tag directly in the interim)

<o​frnxmr:xmr.mx> Since we can tag as often as we like w/o deprecating the "stable" branch too often

<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)

<s​yntheticbird:monero.social> .

<s​yntheticbird:monero.social> We would only be releasing from release branch for hotfix

<s​yntheticbird:monero.social> we won't have two types of release

<t​obtoht:monero.social> yes

<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.

<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>

<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.

<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.

<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.

<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

<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: monero-project/monero #7997

<o​frnxmr:xmr.mx> You dont think branching every 3 months is a mess?

<o​frnxmr:xmr.mx> I think each new branch should be a new major version (18>19>20 etc)

<t​obtoht:monero.social> Doesn't have to be on a schedule. Rather 'branch when ready'.

<s​yntheticbird:monero.social> I see

<t​obtoht:monero.social> That implies features get backported to the release branch.

<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"

<t​obtoht:monero.social> We could still target a specific time-frame. It just doesn't have to be a hard deadline.

<s​yntheticbird:monero.social> ok

<3​21bob321:monero.social> Schedule every orange moon

<o​frnxmr:xmr.mx> So does branching from 19.0>19.1 though (?)

<o​frnxmr:xmr.mx> in your proposal (tob), how often are we branching master (and dropping the prior branch)?

<t​obtoht:monero.social> 19.1 would branch from master, not 19.0

<o​frnxmr:xmr.mx> Wheres 19.0?

<o​frnxmr:xmr.mx> (unrelated but curious)

<s​yntheticbird:monero.social> So to formalize tobtoht proposal:

<s​yntheticbird:monero.social> following semantic versioning

<s​yntheticbird:monero.social> patch versions -> release branch (bug fixes only)

<s​yntheticbird:monero.social> minor versions -> master branch (features+bug fixes)

<s​yntheticbird:monero.social> major versions -> hardfork branch (which is merged into master at shipping time)

<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).

<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.

<s​yntheticbird:monero.social> a release branch is created from master*

<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

<s​yntheticbird:monero.social> hotfix

<s​yntheticbird:monero.social> being responsible enough

<o​frnxmr:xmr.mx> Sounds like the branches are all basically single-use

<s​yntheticbird:monero.social> to ship vuln fix in less than 90 days

<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.

<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

<o​frnxmr:xmr.mx> But then still cut a new branch from master in 3 months?

<s​yntheticbird:monero.social> yes

<s​yntheticbird:monero.social> not a bad tradeoff imo

<s​yntheticbird:monero.social> creating a new branch is one click. revewing two PRs and potentially bisecting a regression take at least a week+

<s​yntheticbird:monero.social> tobtoht mind making an issue so that selsta and others can formalize his thoughts on it

<s​yntheticbird:monero.social> their*

<o​frnxmr:xmr.mx> so the difference between current and proposed, is simply that we branch master / deprecate release more often

<t​obtoht:monero.social> Plus we stop backporting features to the release branch.

<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

<s​yntheticbird:monero.social> there is also the hardfork branch

<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

<s​yntheticbird:monero.social> Less PRs frictions, easier reviews, if we manage to get late on release then it's skill issue ngl

<o​frnxmr:xmr.mx> Like "master updates a b c and we have to support x y z for another 6 months"

<o​frnxmr:xmr.mx> So a) cant branch or b) cant merge prs to master

<s​yntheticbird:monero.social> what is a b c supposed to be ?

<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.

<s​yntheticbird:monero.social> yeah i was going to say this would fall into either hardfork or long-living feature branch

<s​yntheticbird:monero.social> only merged when having to be shipped

<o​frnxmr:xmr.mx> Were on the same page as far as "master should be released every 3-6 months" :)

<o​frnxmr:xmr.mx> i probably just dont like the idea of creating a lot of new branches for the same major version

<s​yntheticbird:monero.social> monero-project/monero #9912

<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.)

<s​yntheticbird:monero.social> edited

<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.

<t​obtoht:monero.social> access to feature branches under monero-project/monero*

<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.

<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 (hebasto/bitcoin #18). Once ready, all changes were submitted in a single PR to master (bitcoin/bitcoin #30454) which then prompted additional review and testing.

<t​obtoht:monero.social> This is similar to what we're doing with the fcmp++-staging branch on seraphis-migration/monero. (github.com/seraphis-migration/monero/pulls).

<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.

<s​yntheticbird:monero.social> I understand

<s​yntheticbird:monero.social> mind adding a comment on the issue

.merge+ 9911

Added

.merges

sech1: can you sign off on 9404 or confirm your comments were addressed

also 9875

<s​yntheticbird:monero.social> 10000th PR when

<0​xfffc:monero.social> Anyone can take look at 9910 ?

<s​yntheticbird:monero.social> i beg two other people to just pull up his branch, and check it in an IDE

<s​yntheticbird:monero.social> also thx 0xfffc