1. Use the LEDE codebase, rather than OpenWrt's (undecided but likely). They'll first push any new changes in OpenWrt since the fork into LEDE, and then rebrand move completely to LEDE's codebase.
2.Will be using OpenWrt's name, not the name 'LEDE' anymore.
3. The workflow is still being discussed. The workflow of both LEDE and Openwrt will be learnt from to come up with the new one. Github will be used for issues, not PRs.
It's not done yet though. I would not be surprised if six months from now they was still petty haggling going on.
>- workflow between LEDE and OpenWrt? Using Github to gather pull requests, but not use the merge pull request feature of Github, have staging trees for queuing changes, and then merge into the main tree
Politically this could mean that either OpenWRT has moved and intends to improve regarding the issues that lead to the fork, or that the fork wants to return home either way.
I suppose at least both groups think their time is better spent together instead of separate, and I personally like these news way more than those of yet another fork...
If there is a re-merge, it's going to be the LEDE base that is used. There are a half-dozen or more new devices supported in LEDE, an no new devices in OpenWRT from after the split (that I am aware of anyway).
Just wanted to put it more into context.
OpenWRT's repository had minor bug fixes in comparison.
The text literally says:
> I am not sure if this is the best way to remove the quirks from the build. Let me know if you prefer a different way of solving this.
"obviously i am interested to get this upstream with the least amount of effort. I am quite aware though that some patches will need an overhaul to be applicable for upstream. its not really my call if it is enough to make this an enable patch and review the quirks enabled by it or if the code needs to be moved."
Upstreaming patches into the kernel requires that you're willing to spend time to rework them so that the result is maintainable. Saying from the start that you only want to do the least amount of work possible isn't helpful.
Iirc openwrt refused to include a kernel patch to make hardware NAT work because it was too much of a hack.
> It is still not decided that both project will finally merge
- merging back together
- using OpenWrt as the merged back project name