On 05/04/2016 11:49 PM, Vittorio G (VittGam) wrote:
> Hi,
>
> On 04/05/2016 22:30:40 CEST, Bert Vermeulen wrote:
>> Hi all,
>>
>> Very happy to see this project reboot happening. An acknowledgement of
>> the issues facing OpenWRT was long overdue. I'd like some clarity on
>> some things that aren't explicitly mentioned in the stated goals,
>> however.
>>
>> First off, is the SVN nonsense definitely gone now? Will the LEDE
>> project be all-git? I assume yes, but would really like to see this
>> confirmed.
LEDE does not use svn.
>> Secondly, the major technical problem OpenWRT faces IMHO has always
>> been the ever-increasing technical debt. In this case this is carried
>> in the form of a *gigantic* number of patches. There are patches for
>> lots of packages, and even the kernel and U-boot. I count over 4700 of
>> them in OpenWRT, 3842 in LEDE right now.
>>
>> This is the sort of thing you expect to see in the internal repo of a
>> company not yet convinced of the benefits of upstreaming; to see this
>> carried in an open source project is downright shocking.
They are probably worse. ;-)
>> I propose to make it an official goal to carry no patches at all;
>> everything should be upstreamed or dropped. That is the only policy
>> that makes any sense at all.
>>
>> Comments, opinions?
>
> I personally don't think "upstream or drop" would be a good thing to do.
>
> Regarding package patches, I think that some are just specific to make
> the package work in an embedded system, and maybe upstream can possibly
> just not be interested in this sometimes.
>
> Regarding U-Boot patches I don't think it's not OpenWrt's fault. For
> example, many Atheros devices use an ancient trunk of U-Boot (1.1.4)
> with many patches from Atheros or router vendors applied to it. Upstream
> might simply not be interested in these patches.
>
> Regarding kernel patches instead, the OpenWrt trunk is/was usually used
> also as a test-bed for some changes that will eventually go upstream at
> some point, and many actually went in the mainline kernel.
>
> Upstreaming kernel patches is usually a long process, and is usually
> meant for finished and polished things, at least to some extent. So you
> can't really experiment with things anymore once it's upstreamed. You
> want to make sure that every rough edge is solved before upstreaming
> something.
>
> Also, upstreaming patches requires some effort/time, and maybe that was
> not always present in OpenWrt, I don't know.
>
> By the way I'm not saying either that trunk is or should be the far-west
> of wild patches... ;)
>
> So, yes, when something is stable enough, and upstream is interested or
> otherwise upstreaming is feasible, then it should be upstreamed. But I
> believe this is already what was happening with OpenWrt...
>
> But, no, when something still needs to be fully tested I think it should
> not be upstreamed yet, and that the OpenWrt/LEDE trunk might just the
> right place for it.
I think we should encourage everyone to upstream the patches, I think in
one of the statics I saw that OpenWrt ranked 3. or 4. in contribution to
the kernel among the Linux distributions before Canonical. ;-)
Only allowing upstream patches also conflicts with the goal to be more
stable and not always use the most recent kernel which introduces new
problems again.
Some kernel patches are also directly extracted from some other
repositories or from some vendors. The raspberry pi patches for example
are exported from some other repository.
Hauke
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
