Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 22/12/2016 08:24, Giuseppe Lippolis wrote: > Dear All, > I started to contribute to LEDE recently and after the spin-off. > When I decided where to port my contribution I considered the "focus on > stability and functionality" more interesting than the "bleeding edge > functionality",

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 22/12/2016 08:06, Russell Senior wrote: >> "Val" == Val Kulkov writes: > >>> Not that a choice on a name, with taste and discretion, isn't going >>> to be needed, but I can't help but think of this: >>> >>> https://en.wikipedia.org/wiki/Law_of_triviality >>> >>>

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

Dear All, I started to contribute to LEDE recently and after the spin-off. When I decided where to port my contribution I considered the "focus on stability and functionality" more interesting than the "bleeding edge functionality", therefore I selected LEDE. Now I understand that a merge is

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

OpenLEDE - /ˈōpənlēdē/ On Wed, Dec 21, 2016 at 11:06 PM, Russell Senior wrote: > > Val> Now, please try to explain how to pronounce OpenLEDE and make sure > Val> the correct pronunciation sticks :-) > > It doesn't matter how they pronounce it, as long as they can

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 22/12/2016 04:45, Dave Taht wrote: > Lede trademark... > > Published for Opposition:December 20, 2016 > > sigh. > *slap on the wrist or top posting* the project is called lede-project and not lede for a reason ;) John > On Wed, Dec 21, 2016 at 7:36 PM, Val Kulkov

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 22/12/2016 06:18, Val Kulkov wrote: > On 22 December 2016 at 00:13, Russell Senior > wrote: >>> "Florian" == Florian Fainelli writes: >> However, I also agree with Dave, Alberto and Stefan that a name change may be a really

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

> "Val" == Val Kulkov writes: >> Not that a choice on a name, with taste and discretion, isn't going >> to be needed, but I can't help but think of this: >> >> https://en.wikipedia.org/wiki/Law_of_triviality >> >> >> PS: OpenLEDE. ;-) Val> Now, please try to explain

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 22 December 2016 at 00:13, Russell Senior wrote: >> "Florian" == Florian Fainelli writes: > >>> However, I also agree with Dave, Alberto and Stefan that a name >>> change may be a really smart way to communicate the fresh start of >>> the

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

> OpenWrt is widely known... as a bleeding edge, > sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt > and Tomato get a lot more press for some reason. I seem to agree with this -- As a user, I have been using Tomato and DD-WRT until very recently, exactly because I tried

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

Lede trademark... Published for Opposition:December 20, 2016 sigh. On Wed, Dec 21, 2016 at 7:36 PM, Val Kulkov wrote: > On 21 December 2016 at 17:01, Florian Fainelli wrote: >> On 12/21/2016 01:46 PM, Alberto Bursi wrote: >>> On 12/21/2016 09:42 PM,

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 21 December 2016 at 17:01, Florian Fainelli wrote: > On 12/21/2016 01:46 PM, Alberto Bursi wrote: >> On 12/21/2016 09:42 PM, Dave Taht wrote: >>> On Wed, Dec 21, 2016 at 12:29 PM, David Lang wrote: On Wed, 21 Dec 2016, Kathy Giori wrote: >

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 12/21/2016 07:30 PM, Val Kulkov wrote: > > On 21 December 2016 at 17:01, Florian Fainelli > wrote: > > On 12/21/2016 01:46 PM, Alberto Bursi wrote: > > On 12/21/2016 09:42 PM, Dave Taht wrote: > >> On Wed, Dec 21, 2016 at 12:29

Re: [LEDE-DEV] Talks between OpenWrt and LEDE

> Yocto. If lede were to succeed in meeting its other goals, coherently, > preserving "lede" and moving forward as a separate project does make > sense. I don't have a clear opinion either way, but I think there are several points to take into account: - OpenWRT indeed has a fair bit of positive

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 12/21/2016 01:46 PM, Alberto Bursi wrote: > On 12/21/2016 09:42 PM, Dave Taht wrote: >> On Wed, Dec 21, 2016 at 12:29 PM, David Lang wrote: >>> On Wed, 21 Dec 2016, Kathy Giori wrote: >>> From a PR perspective, I strongly suggest keeping the term OpenWrt as part of the

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On 12/21/2016 09:42 PM, Dave Taht wrote: > On Wed, Dec 21, 2016 at 12:29 PM, David Lang wrote: >> On Wed, 21 Dec 2016, Kathy Giori wrote: >> >>> From a PR perspective, I strongly suggest keeping the term OpenWrt as >>> part of the branding of the project moving forward. It can just

Re: [LEDE-DEV] [PATCH netifd] proto: allow configuring deprecated static IPv6 addresses

On 12/21/2016 09:51 PM, Hans Dedecker wrote: > On Mon, Dec 19, 2016 at 10:10 PM, Matthias Schiffer > wrote: >> On 12/19/2016 10:02 PM, Hans Dedecker wrote: >>> On Sun, Dec 11, 2016 at 3:03 AM, Matthias Schiffer >>> wrote: Add a

Re: [LEDE-DEV] [PATCH netifd] proto: allow configuring deprecated static IPv6 addresses

On Mon, Dec 19, 2016 at 10:10 PM, Matthias Schiffer wrote: > On 12/19/2016 10:02 PM, Hans Dedecker wrote: >> On Sun, Dec 11, 2016 at 3:03 AM, Matthias Schiffer >> wrote: >>> Add a new boolean attribute ip6preferred to the static

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On Wed, Dec 21, 2016 at 12:29 PM, David Lang wrote: > On Wed, 21 Dec 2016, Kathy Giori wrote: > >> From a PR perspective, I strongly suggest keeping the term OpenWrt as >> part of the branding of the project moving forward. It can just be >> cosmetic (web site, etc.) but the name

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On Wed, 21 Dec 2016, Kathy Giori wrote: From a PR perspective, I strongly suggest keeping the term OpenWrt as part of the branding of the project moving forward. It can just be cosmetic (web site, etc.) but the name has so much history, and positive connotation, that you don't want to lose that

Re: [LEDE-DEV] Release planning

On Wed, 21 Dec 2016, Jo-Philipp Wich wrote: - set grace period of 5 days to identify and fix blockers day 16 - extend grace period by 5 days until blockers are resolved As a practical matter, make these 7 days rather than 5 days. the shift between the work-week and the release

Re: [LEDE-DEV] Release planning

On 21/12/2016 20:23, Dave Taht wrote: > a) It is obviously my sincere hope that the wifi airtime fairness > patches make this release. > > b) is there any plan in the cards to fund a "stable maintainer", or > otherwise make assurances, that a stable release will be maintained > for X time? i

Re: [LEDE-DEV] RFC: splitting up the patches folder

On 21/12/2016 20:21, Florian Fainelli wrote: > Hallo, > > On 12/20/2016 12:53 PM, John Crispin wrote: >> Hi, >> >> i have been thinking of how to split up the kernel patches folder in a >> better way. for a start we have all the backports inside the same folder >> as our normal patches,

Re: [LEDE-DEV] Release planning

a) It is obviously my sincere hope that the wifi airtime fairness patches make this release. b) is there any plan in the cards to fund a "stable maintainer", or otherwise make assurances, that a stable release will be maintained for X time? c) I am curious as to what "big changes" are pending

Re: [LEDE-DEV] RFC: splitting up the patches folder

Hallo, On 12/20/2016 12:53 PM, John Crispin wrote: > Hi, > > i have been thinking of how to split up the kernel patches folder in a > better way. for a start we have all the backports inside the same folder > as our normal patches, unfortunately we have some backports and patches > that have in

[LEDE-DEV] Release planning

Hi guys, I spent the last few weeks working on automating the release procedure as much as possible and am now mostly satisfied with the result. Currently, I am reusing most parts of the existing build bot logic and developed some scripts to automate the setup of release build bots and to

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

Hi all, To clarify, the reason for integrating the OpenWrt patches into the LEDE tree is that in the future, at an agreed point in time for both parties, the OpenWrt trunk would be rebased from the LEDE tree, giving the community a "clean" trunk going forward. (Hopefully at that time, the

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

Great achievement. Congratulations to all involved. On the naming topic have in mind the weight OpenWRT has given its history in all these years. I personally think this point is the easiest. Given the agreements continue hopefully there will be a single one great project again soon with all

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

On Wed, Dec 21, 2016 at 10:06 AM, Hauke Mehrtens wrote: > We had multiple meetings to find a solution to solve the problems > between the OpenWrt and the LEDE project and to discuss a possible > merge. Everyone with commit access to LEDE and all OpenWrt core > developers were

[LEDE-DEV] Talks between OpenWrt and LEDE

We had multiple meetings to find a solution to solve the problems between the OpenWrt and the LEDE project and to discuss a possible merge. Everyone with commit access to LEDE and all OpenWrt core developers were invited to these meetings. We had productive and friendly discussions about the

Re: [LEDE-DEV] gateworks patches in the tree

On Wed, Dec 21, 2016 at 1:54 AM, John Crispin wrote: > Hi Tim, > Hi John, > we currently have these patches in the tree, which i think you were > involved in. could you tell us which of these can be sent upstream > and/or what is blocking us sending them upstream ? > >

[LEDE-DEV] BUG in musl ?

So I have an issue when I link against libnl. this is on a mipsel target. test program is just an empty main() cat main.c int main() { return 0; } compile with mipsel-openwrt-linux-gcc -o failure -lnl-route-3 main.c then run the program on target

[LEDE-DEV] gateworks patches in the tree

Hi Tim, we currently have these patches in the tree, which i think you were involved in. could you tell us which of these can be sent upstream and/or what is blocking us sending them upstream ? 160-usb-gadget-udc-net2280-add-usb2380-support.patch:From: Tim Harvey

Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch

On 21/12/2016 10:48, Jonas Gorski wrote: > On 21 December 2016 at 10:42, John Crispin wrote: >> >> >> On 21/12/2016 09:39, Jonas Gorski wrote: >>> On 21 December 2016 at 09:34, John Crispin wrote: On 21/12/2016 09:31, Jonas Gorski wrote: >

[LEDE-DEV] [PATCH] kernel: drop 702-phy_add_aneg_done_function.patch

The kernel provides a link_change_notify callback these days, making the patch obselete. Drop the patch and make its only user use the new API. Signed-off-by: John Crispin --- .../linux/generic/files/drivers/net/phy/ip17xx.c |4 +-

Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch

On 21 December 2016 at 10:42, John Crispin wrote: > > > On 21/12/2016 09:39, Jonas Gorski wrote: >> On 21 December 2016 at 09:34, John Crispin wrote: >>> >>> >>> On 21/12/2016 09:31, Jonas Gorski wrote: Hi, On 21 December 2016 at 09:21, John

Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch

On 21/12/2016 09:39, Jonas Gorski wrote: > On 21 December 2016 at 09:34, John Crispin wrote: >> >> >> On 21/12/2016 09:31, Jonas Gorski wrote: >>> Hi, >>> >>> On 21 December 2016 at 09:21, John Crispin wrote: This patch makes 3 symbols default, that get

Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch

On 21 December 2016 at 09:34, John Crispin wrote: > > > On 21/12/2016 09:31, Jonas Gorski wrote: >> Hi, >> >> On 21 December 2016 at 09:21, John Crispin wrote: >>> This patch makes 3 symbols default, that get selected by the according code. >>> >>>

Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch

On 21/12/2016 09:31, Jonas Gorski wrote: > Hi, > > On 21 December 2016 at 09:21, John Crispin wrote: >> This patch makes 3 symbols default, that get selected by the according code. >> >> arch/mips/bcm47xx/Kconfig: select SSB_B43_PCI_BRIDGE if PCI >>

Re: [LEDE-DEV] [PATCH] kernel: drop superflous b43 patch

Hi, On 21 December 2016 at 09:21, John Crispin wrote: > This patch makes 3 symbols default, that get selected by the according code. > > arch/mips/bcm47xx/Kconfig: select SSB_B43_PCI_BRIDGE if PCI > drivers/net/wireless/broadcom/b43legacy/Kconfig:select >

[LEDE-DEV] [PATCH] kernel: drop superflous b43 patch

This patch makes 3 symbols default, that get selected by the according code. arch/mips/bcm47xx/Kconfig: select SSB_B43_PCI_BRIDGE if PCI drivers/net/wireless/broadcom/b43legacy/Kconfig:select SSB_B43_PCI_BRIDGE drivers/net/wireless/broadcom/b43/Kconfig: select