OpenWrt and LEDE to re-merge | Hacker News Reader

OpenWrt and LEDE to re-merge

lists.infradead.org

270 pointssamcrawford27 comments

This is awesome! So this is some of the important stuff:

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.

I follow OpenWRT/LEDE fairly closely and I agree that these bullet points are most likely the outcomes. Basically, in a sentence, LEDE may be allowed to take over management of the OpenWRT assets.

It's not done yet though. I would not be surprised if six months from now they was still petty haggling going on.

Are you sure about #3? I read it issues are not to be used but PR are.

You're right #3 is not right, but its not completely wrong either. Looks like issues on github won't be used, but PRs won't really be used since there isn't going to be any merging done using PRs. Maybe it'll be a bit more clear as to what they'll do. I wonder what's left for them to host on github if people can't open issues or merge their code.

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

The forked from OpenWRT in May 2016 and are now already going back. I guess there's not much to gain from the code merge for end users except for a few bug fixes (https://lede-project.org/faq#were_there_any_technical_reason...).

Well, technically you might be right, but I would like to point out that two groups joining their efforts, while picking the best of both (organizational) worlds (processes, infrastructure, etc.) is always a good thing in the open-source world and means progress could be accelerated for the new, unified project.

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

Yes. It's so rare to find people willing to cooperate and make some compromises for much larger overarching productivity. The BFG and Pylons merged to become Pyramid after recognizing that they were working toward a very similar vision and that it was just wasted effort to be getting there separately. It's always great to hear of this kind of thing, and I have huge respect for the people behind the few projects that are willing to do it.

From what I've gathered so far, LEDE is where the vast majority of activity and development moved after OpenWRT alienated most of the participants with friction in their workflow. OpenWRT had just a shell of 3 project members left, but continued to have substantial name recognition.

This is correct. LEDE is where all the devs and action went. OpenWRT is now just two or three people who were holding the old project hostage and may agree for LEDE to take over the name.

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

Sounds reminiscent of the nodejs/iojs split and re-merge.

Sure, don't get me wrong, I think it's great that they put aside their differences and decided to work together again. I agree that focusing of one project is better.

Just wanted to put it more into context.

Avoiding an ongoing fork shows a great deal of maturity. Way better than merging a fork that's 5 years out.

If you look at the pace and scope of commits on the LEDE codebase, it's dramatically increased from OpenWRT. It's far more than "a few bug fixes", they've substantially rewritten the codebase and updated its dependencies. Meanwhile the OpenWRT codebase has been stagnant (since most developers went to LEDE where their commits could actually make it in). The merge replaces the OpenWRT organization infra with LEDE's, allowing LEDE's pace of innovation to continue. That's the main gain.

As far as development resources were concerned, LEDE was OpenWRT. There is no noticeable difference in development activity before/after the fork when looking at git commits:

https://github.com/lede-project/source/graphs/code-frequency

OpenWRT's repository had minor bug fixes in comparison.

I really wish the openwrt software ecosystem wasn't in its own little world, things like ubus + augeus would be nice.

LEDE folks have started to dump their patches on kernel mailing lists, but they don't seem to be mainline-able as is and the submitter is loathe to rework them:

http://marc.info/?l=linux-kernel&m=148230680302480&w=2

Perhaps there is more context, but from a narrow read: the linked email states a need, contains a patch that solves the problem, and offers to solve it another way if needed... that seems pretty mature?

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.

I can speak from experience that some of the LEDE/OpenWRT core people are fairly toxic at times. John Crispin in particular is known to go autistic on you if you top-post on one of his mailing lists instead of bottom-post. He's a real laces-out kinda guy.

You need to read the whole thread:

http://marc.info/?l=linux-pci&m=148238610022972&w=2

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

The majority of OpenWRT/LEDE patches are gross hacks that need a major rework or a completely different approach. This is not the first patch of that kind.

Do you have a source for that?

Iirc openwrt refused to include a kernel patch to make hardware NAT work because it was too much of a hack.

best news for Christmas!

The submission title "OpenWrt and LEDE to re-merge" doesn't match the post which is titled "Talks between OpenWrt and LEDE" and specifically says:

> It is still not decided that both project will finally merge

It's the record of more than one meeting. Check out the part under 'OpenWrt / LEDE follow up meeting'.

My bad, I thought the first section was a summary and skipped the rest.

I did exactly the same thing.

> 1. Results from meeting at prpl OpenWrt summit

Agreed upon:

- merging back together - using OpenWrt as the merged back project name

Reply on news.ycombinator.com