diff mbox series

[19.07] feeds.conf.default: remove freifunk feed

Message ID 20220227111247.7677-1-ynezz@true.cz
State Deferred
Delegated to: Petr Štetiar
Headers show
Series [19.07] feeds.conf.default: remove freifunk feed | expand

Commit Message

Petr Štetiar Feb. 27, 2022, 11:12 a.m. UTC
From: Perry Melange <isprotejesvalkata@gmail.com>

The freifunk feed is being removed becasue
a) it is an external project and the OpenWrt team does not have access to it.
b) upon original addition of the feed, there was only a very weak tendency for
the addition.
c) there is a general lack of interest in the freifunk repo to review and/or
merge pull requests.
d) as far as can be found, all projects which use the freifunk feed have their
own make system and self-maintained feeds list.  They do not use the
feeds.conf.default from the openwrt repo.

more information can be read at the following links:

http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033807.html
https://github.com/freifunk/openwrt-packages/issues/37

Suggested-by: Josef Schlehofer <josef.schlehofer@nic.cz>
Signed-off-by: Perry Melange <isprotejesvalkata@gmail.com>
(cherry picked from commit 20caa68fec4fe033f72c9d488639f8dd2bcfa02c)
(cherry picked from commit ff6b36b9548bbb869c2f5a5ffc0e415e25bc857e)
---
 feeds.conf.default | 1 -
 1 file changed, 1 deletion(-)

Comments

Paul Spooren Feb. 27, 2022, 2:29 p.m. UTC | #1
> On 27. Feb 2022, at 12:12, Petr Štetiar <ynezz@true.cz> wrote:
> 
> From: Perry Melange <isprotejesvalkata@gmail.com>
> 
> The freifunk feed is being removed becasue
> a) it is an external project and the OpenWrt team does not have access to it.
> b) upon original addition of the feed, there was only a very weak tendency for
> the addition.
> c) there is a general lack of interest in the freifunk repo to review and/or
> merge pull requests.
> d) as far as can be found, all projects which use the freifunk feed have their
> own make system and self-maintained feeds list.  They do not use the
> feeds.conf.default from the openwrt repo.
> 
> more information can be read at the following links:
> 
> http://lists.openwrt.org/pipermail/openwrt-devel/2021-February/033807.html
> https://github.com/freifunk/openwrt-packages/issues/37
> 
> Suggested-by: Josef Schlehofer <josef.schlehofer@nic.cz>
> Signed-off-by: Perry Melange <isprotejesvalkata@gmail.com>
> (cherry picked from commit 20caa68fec4fe033f72c9d488639f8dd2bcfa02c)
> (cherry picked from commit ff6b36b9548bbb869c2f5a5ffc0e415e25bc857e)
> ---

Isn’t it bad to backport package (or even feed) removal?

> feeds.conf.default | 1 -
> 1 file changed, 1 deletion(-)
> 
> diff --git a/feeds.conf.default b/feeds.conf.default
> index ad32ec8f4e65..42c2b0ba3b93 100644
> --- a/feeds.conf.default
> +++ b/feeds.conf.default
> @@ -2,4 +2,3 @@ src-git packages https://git.openwrt.org/feed/packages.git;openwrt-19.07
> src-git luci https://git.openwrt.org/project/luci.git;openwrt-19.07
> src-git routing https://git.openwrt.org/feed/routing.git;openwrt-19.07
> src-git telephony https://git.openwrt.org/feed/telephony.git;openwrt-19.07
> -src-git freifunk https://github.com/freifunk/openwrt-packages.git;openwrt-19.07
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Petr Štetiar Feb. 27, 2022, 8:16 p.m. UTC | #2
Paul Spooren <mail@aparcar.org> [2022-02-27 15:29:22]:

Hi,

> Isn’t it bad to backport package (or even feed) removal?

if it's not maintained, what other options are there? FYI this feed was
backported into 19.07.5.

Anyway, this release is almost EOL, so I don't think, that this backport has
other then documentation value, but I've just tried to help with following
request[1].

1. https://github.com/openwrt/openwrt/commit/ff6b36b9548bbb869c2f5a5ffc0e415e25bc857e#commitcomment-67529159

Cheers,

Petr
Josef Schlehofer Feb. 28, 2022, 12:40 a.m. UTC | #3
Hello,

On 27. 02. 22 15:29, Paul Spooren wrote:
> Isn’t it bad to backport package (or even feed) removal?

This feed was removed before OpenWrt 21.02-rc1 was released, but it was 
you, Paul, who asked if it could be backported to OpenWrt 19.07 based on 
this comment [1], and a few days later, it was cherry-picked. [2]

It could be interesting to know why it was necessary to include it in 
the stable release and if you need it somehow. As said, this feed has 
been present since OpenWrt 19.07.5, but given the reasons in the commit 
message and as it was removed from openwrt-21.02 and master branches, it 
is not necessary to have it in OpenWrt 19.07.

  If it is not used anymore, then it could be removed.


[1] 
https://github.com/openwrt/openwrt/commit/221f97ff4737f012c90feb086bc1c2ed86c6001b#commitcomment-43920797

[2] 
https://github.com/openwrt/openwrt/commit/2a3dbded93775aeaf28fbebbd6aada07c9f588c1

Regards,
Josef
Paul Spooren Feb. 28, 2022, 9:04 a.m. UTC | #4
Hi

> On 27. 02. 22 15:29, Paul Spooren wrote:
>> Isn’t it bad to backport package (or even feed) removal?
> 
> This feed was removed before OpenWrt 21.02-rc1 was released, but it was you, Paul, who asked if it could be backported to OpenWrt 19.07 based on this comment [1], and a few days later, it was cherry-picked. [2]
> 
> It could be interesting to know why it was necessary to include it in the stable release and if you need it somehow. As said, this feed has been present since OpenWrt 19.07.5, but given the reasons in the commit message and as it was removed from openwrt-21.02 and master branches, it is not necessary to have it in OpenWrt 19.07.
> 
>  If it is not used anymore, then it could be removed.

I’m a fan of the Freifunk work however I don’t use it myself. Backporting it to 19.07.x allows all previous releases to add the feed and use it. I hoped to see some unification of the many Freifunk flavors by having a single “official” repository. Since that didn’t work out I’m fine that it was dropped later on.

Being part of the OpenWrt project I learn every other day that “legacy” shouldn’t be broken. By removing the Freifunk feed we may break whatever special setup some community somewhere figured out, glued into some CI and scripts which silently produces images for whatever use case.

Anyway, if the Freifunk community itself finds it to be useless, let’s drop it. 19.07 is EOL soonish like Petr said.

> 
> 
> [1] https://github.com/openwrt/openwrt/commit/221f97ff4737f012c90feb086bc1c2ed86c6001b#commitcomment-43920797
> 
> [2] https://github.com/openwrt/openwrt/commit/2a3dbded93775aeaf28fbebbd6aada07c9f588c1
> 
> Regards,
> Josef
>
Nick Feb. 28, 2022, 12:17 p.m. UTC | #5
On 2/28/22 10:04, Paul Spooren wrote:

> Anyway, if the Freifunk community itself finds it to be useless, let’s drop it.
I don't think it's useless to combine Freifunk and OpenWrt. I don't know 
why people pulled for example the freifunk luci mod out of OpenWrt Luci 
Feed. Now we don't benefit anymore from tree-wide changes. I had a hard 
time converting the mod to 19.07 and then 21.02 (thanks a lot to jow who 
supported me). From my side of view, we lack maintainer power, to allow 
us to follow each tree-wide change and apply them. However, I think 
OpenWrt especially benefits from all Freifunk-Communities, since we do 
maintenance, testing, and development. For example I am part of Freifunk 
Berlin (however, we have 3(?) different "firmwares" right now).
Freifunk communities often rely on the "openwrt routing feed". In my 
view, it consists only of two real active maintenance (mwarning and me 
and maybe some more). Now thankfully BKPepe and neheb help to maintain 
the feed and get it into a good-looking shape. There is a lot of power 
in the community package repository. Somehow more and more stuff is 
maintained from my side I never planned to do so. For example, I 
currently maintain OLSR. I would be very happy if we could upstream 
again more wireless community mesh-specific packages to OpenWrt and get 
more help with maintenance. So that in the end, more resources are free 
to develop and test more.
Some people in Berlin switched to an "ansiblification" of the most 
important backbone places in our network, that completely builds on 
normal OpenWrt [0] utilizing the image builders. So at least some 
Freifunk don't use their own make system modification. I always argue to 
make things more generalized so all people using OpenWrt can benefit 
from it, and we don't have to write the same code (or even maintain the 
same packages) multiple times, e.g. tunneldigger.

Overall, instead of maintaining a separate feed for Freifunk where we 
also have to maintain the CIs and so on, I would argue for more packages 
in openwrt/packages and openwrt/luci. It is not about all the "uci 
config defaults" that are in the Freifunk repository. In my view, we 
need to just generate default configs differently, like we already do in 
ansible and feed them into the imagebuilder. It is about packages that 
have some more functionality, like showing mesh routing protocols on the 
front page, building WireGuard tunnels, etc. ... So remove the Freifunk 
Repository, but let's work/maintain together.

Bests
Nick

[0] - https://github.com/freifunk-berlin/bbb-configs
diff mbox series

Patch

diff --git a/feeds.conf.default b/feeds.conf.default
index ad32ec8f4e65..42c2b0ba3b93 100644
--- a/feeds.conf.default
+++ b/feeds.conf.default
@@ -2,4 +2,3 @@  src-git packages https://git.openwrt.org/feed/packages.git;openwrt-19.07
 src-git luci https://git.openwrt.org/project/luci.git;openwrt-19.07
 src-git routing https://git.openwrt.org/feed/routing.git;openwrt-19.07
 src-git telephony https://git.openwrt.org/feed/telephony.git;openwrt-19.07
-src-git freifunk https://github.com/freifunk/openwrt-packages.git;openwrt-19.07