Return to trunk

[jjtolton]

Hey everyone, we need to consolidate these feature branches into a parallel main branch so that it is easy for @mthom to merge them in when then time comes. We have a number of excellent feature branches floating around right now but we are fragmenting from the trunk significantly. This especially pertains to a significant amount of the work @bakaq has done lately that are important upgrades, and many others that I am less aware of.

Also in case anyone thinks this is crazy, I understand -- feature branching is the status quo. However, trunk based development is the norm in continuous delivery style development, it's not the same as cutting a release.

Please comment below with branches required, I will put together a spreadsheet to manage them.

[triska]

Thank you all for your great work and pending contributions! The current situation is a bit unusual in that significant changes are pending in the rebis-dev development branch, and a few unresolved issues remain: #2574

The rebis-dev development branch is currently different from master to such an extent that it requires also existing PRs to be adapted, such as #2796. There are also already pending PRs specifically for rebis-dev, such as #2764 and #2759.

Personally, I think it would be most helpful and promising to focus on getting rebis-dev ready to merge into master, and thus have a much more solid basis for further and also interrelated changes on top of this.

[jjtolton]

Yes, that would be most desirable. Is there anything in particular we can do to ensure rebis-dev compatibility or push that forward?

[jjtolton]

aka should we branch from rebis-dev instead of main?

[triska]

In my personal opinion: yes, all ongoing core engine development is ideally already based on rebis-dev, since this is the latest state of core development, laying the foundation for real tests of the system due to its improved memory allocation and reclamation on backtracking, and an ideal outcome of this is to get more people to help address the few remaining issues in rebis-dev in the process, so that it can be merged.

Prolog-based contributions can be added to either branch since they run the same in both branches and will therefore be very easy to merge.

[bakaq]

I tried to be careful to not introduce extra conflicts with @mthom's rebis-dev or @aarroyoc's #2424 in my recent contributions. I want to eventually do some stuff deeper in the engine but that will require some coordination with them.