Re: Release goals for 22.XX
On Thu, 7 Oct 2021 at 00:33, Hauke Mehrtens wrote: > > On 10/6/21 12:33 AM, Robert Marko wrote: > > On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote: > >> > >> Hi all, > >> > >> based on my overview[1] things are moving forward and being tested, > >> great! What about the targets that did not see any 5.10 ambitions yet? > >> Specifically: > >> > >> - arc770 > >> - archs38 > >> - ath25 > >> - bcm47xx > >> - bcm4908 > >> - ipq807x > > > > I can say that Ansuel Smith and I have been working on the IPQ807x support. > > It's still rough when it comes to networking but I have been trying to > > upstream other stuff slowly. > > We were planning to make a PR adding support for most stuff soon and > > it would be 5.10 only or > > even better 5.15 if that lands into OpenWrt soon. > > > > Regards, > > Robert > > Hi Robert, > > It would be really nice to have ipq807x in the next release and thanks > for also getting this integrated upstream. > > Is this NSS firmware mandatory or will networking also work without it? > https://github.com/robimarko/nss-packages It should work without NSS as well, but it looks like there may be a bug that without the NSS FW networking speeds are really low. That is something I need to test further, but another issue is that the wired driver is pretty bad without offloading, it has a non-NSS mode but the throughput is rather bad as it only uses one set of interrupts and hogs the CPU0. It also fakes the switch ports as netdevs and thus breaks the FDB and roaming, so it is the usual QCA mess. Regards, Robert > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 10/6/21 12:33 AM, Robert Marko wrote: On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote: Hi all, based on my overview[1] things are moving forward and being tested, great! What about the targets that did not see any 5.10 ambitions yet? Specifically: - arc770 - archs38 - ath25 - bcm47xx - bcm4908 - ipq807x I can say that Ansuel Smith and I have been working on the IPQ807x support. It's still rough when it comes to networking but I have been trying to upstream other stuff slowly. We were planning to make a PR adding support for most stuff soon and it would be 5.10 only or even better 5.15 if that lands into OpenWrt soon. Regards, Robert Hi Robert, It would be really nice to have ipq807x in the next release and thanks for also getting this integrated upstream. Is this NSS firmware mandatory or will networking also work without it? https://github.com/robimarko/nss-packages Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] hostapd: ubus: add BSS transtiton request method
The existing wnm_disassoc_imminent ubus method only supports issuing a
bss transition request with the disassoc imminent flag set.
For use-cases, where the client is requested to roam to another BSS
without a pending disassoc, this existing method is not suitable.
Add a new bss_transition_request ubus method, which provides a more
universal way to dispatch a transition request. It takes the following
arguments:
Required:
addr: String - MAC-address of the STA to send the request to (colon-seperated)
Optional:
abridged - Bool - Indicates if the abridged flag is set
disassociation_imminent: Bool - Whether or not the disassoc_imminent
flag is set
disassociation_timer: I32 - number of TBTTs after which the client will
be disassociated
validity_period: I32 - number of TBTTs after which the beacon
candidate list (if included) will be invalid
neighbors: blob-array - Array of strings containing neighbor reports as
hex-string
Signed-off-by: David Bauer
---
.../services/hostapd/src/src/ap/ubus.c| 152 +-
1 file changed, 112 insertions(+), 40 deletions(-)
diff --git a/package/network/services/hostapd/src/src/ap/ubus.c
b/package/network/services/hostapd/src/src/ap/ubus.c
index 367e1b652b..1b5c60416f 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -1275,60 +1275,30 @@ hostapd_rrm_beacon_req(struct ubus_context *ctx, struct
ubus_object *obj,
#ifdef CONFIG_WNM_AP
-enum {
- WNM_DISASSOC_ADDR,
- WNM_DISASSOC_DURATION,
- WNM_DISASSOC_NEIGHBORS,
- WNM_DISASSOC_ABRIDGED,
- __WNM_DISASSOC_MAX,
-};
-
-static const struct blobmsg_policy wnm_disassoc_policy[__WNM_DISASSOC_MAX] = {
- [WNM_DISASSOC_ADDR] = { "addr", BLOBMSG_TYPE_STRING },
- [WNM_DISASSOC_DURATION] { "duration", BLOBMSG_TYPE_INT32 },
- [WNM_DISASSOC_NEIGHBORS] { "neighbors", BLOBMSG_TYPE_ARRAY },
- [WNM_DISASSOC_ABRIDGED] { "abridged", BLOBMSG_TYPE_BOOL },
-};
static int
-hostapd_wnm_disassoc_imminent(struct ubus_context *ctx, struct ubus_object
*obj,
- struct ubus_request_data *ureq, const char
*method,
- struct blob_attr *msg)
+hostapd_bss_tr_send(struct hostapd_data *hapd, u8 *addr, bool
disassoc_imminent, bool abridged,
+ u16 disassoc_timer, u8 validity_period, struct blob_attr
*neighbors)
{
- struct hostapd_data *hapd = container_of(obj, struct hostapd_data,
ubus.obj);
- struct blob_attr *tb[__WNM_DISASSOC_MAX];
struct blob_attr *cur;
struct sta_info *sta;
- int duration = 10;
- int rem;
int nr_len = 0;
+ int rem;
u8 *nr = NULL;
- u8 req_mode = WNM_BSS_TM_REQ_DISASSOC_IMMINENT;
- u8 addr[ETH_ALEN];
-
- blobmsg_parse(wnm_disassoc_policy, __WNM_DISASSOC_MAX, tb,
blob_data(msg), blob_len(msg));
-
- if (!tb[WNM_DISASSOC_ADDR])
- return UBUS_STATUS_INVALID_ARGUMENT;
-
- if (hwaddr_aton(blobmsg_data(tb[WNM_DISASSOC_ADDR]), addr))
- return UBUS_STATUS_INVALID_ARGUMENT;
-
- if ((cur = tb[WNM_DISASSOC_DURATION]) != NULL)
- duration = blobmsg_get_u32(cur);
+ u8 req_mode = 0;
sta = ap_get_sta(hapd, addr);
if (!sta)
return UBUS_STATUS_NOT_FOUND;
- if (tb[WNM_DISASSOC_NEIGHBORS]) {
+ if (neighbors) {
u8 *nr_cur;
- if (blobmsg_check_array(tb[WNM_DISASSOC_NEIGHBORS],
+ if (blobmsg_check_array(neighbors,
BLOBMSG_TYPE_STRING) < 0)
return UBUS_STATUS_INVALID_ARGUMENT;
- blobmsg_for_each_attr(cur, tb[WNM_DISASSOC_NEIGHBORS], rem) {
+ blobmsg_for_each_attr(cur, neighbors, rem) {
int len = strlen(blobmsg_get_string(cur));
if (len % 2)
@@ -1344,7 +1314,7 @@ hostapd_wnm_disassoc_imminent(struct ubus_context *ctx,
struct ubus_object *obj,
}
nr_cur = nr;
- blobmsg_for_each_attr(cur, tb[WNM_DISASSOC_NEIGHBORS], rem) {
+ blobmsg_for_each_attr(cur, neighbors, rem) {
int len = strlen(blobmsg_get_string(cur)) / 2;
*nr_cur++ = WLAN_EID_NEIGHBOR_REPORT;
@@ -1361,15 +1331,116 @@ hostapd_wnm_disassoc_imminent(struct ubus_context
*ctx, struct ubus_object *obj,
if (nr)
req_mode |= WNM_BSS_TM_REQ_PREF_CAND_LIST_INCLUDED;
- if (tb[WNM_DISASSOC_ABRIDGED] &&
blobmsg_get_bool(tb[WNM_DISASSOC_ABRIDGED]))
+ if (abridged)
req_mode |= WNM_BSS_TM_REQ_ABRIDGED;
- if (wnm_send_bss_tm_req(hapd, sta, req_mode, duration, duration, NULL,
+ if (disassoc_imminent)
+ req_mode |= WNM_BSS_TM_REQ_DISASSOC_IMMINENT;
+
+ if
[PATCH] hostapd: ubus: add notification for BSS transition response
To allow steering daemons to be aware of the STA-decided transition
target, publish WNM transition responses to ubus. This way, steerings
daemons can learn about STA-chosen targets and send a better selection
of transition candidates.
Signed-off-by: David Bauer
---
.../hostapd/patches/600-ubus_support.patch| 30 +
.../services/hostapd/src/src/ap/ubus.c| 33 +++
.../services/hostapd/src/src/ap/ubus.h| 11 +++
3 files changed, 74 insertions(+)
diff --git a/package/network/services/hostapd/patches/600-ubus_support.patch
b/package/network/services/hostapd/patches/600-ubus_support.patch
index 005ed54e0c..d77d245243 100644
--- a/package/network/services/hostapd/patches/600-ubus_support.patch
+++ b/package/network/services/hostapd/patches/600-ubus_support.patch
@@ -514,3 +514,33 @@
struct os_reltime backlogged_until;
#endif /* CONFIG_AIRTIME_POLICY */
+--- a/src/ap/wnm_ap.c
b/src/ap/wnm_ap.c
+@@ -463,7 +463,7 @@ static void ieee802_11_rx_bss_trans_mgmt
+ size_t len)
+ {
+ u8 dialog_token, status_code, bss_termination_delay;
+- const u8 *pos, *end;
++ const u8 *pos, *end, *target_bssid;
+ int enabled = hapd->conf->bss_transition;
+ struct sta_info *sta;
+
+@@ -510,6 +510,7 @@ static void ieee802_11_rx_bss_trans_mgmt
+ wpa_printf(MSG_DEBUG, "WNM: not enough room for Target
BSSID field");
+ return;
+ }
++ target_bssid = pos;
+ sta->agreed_to_steer = 1;
+ eloop_cancel_timeout(ap_sta_reset_steer_flag_timer, hapd, sta);
+ eloop_register_timeout(2, 0, ap_sta_reset_steer_flag_timer,
+@@ -529,6 +530,10 @@ static void ieee802_11_rx_bss_trans_mgmt
+ MAC2STR(addr), status_code, bss_termination_delay);
+ }
+
++ hostapd_ubus_notify_bss_transition_response(hapd, sta->addr,
dialog_token,
++ status_code,
bss_termination_delay,
++ target_bssid, pos, end -
pos);
++
+ wpa_hexdump(MSG_DEBUG, "WNM: BSS Transition Candidate List Entries",
+ pos, end - pos);
+ }
diff --git a/package/network/services/hostapd/src/src/ap/ubus.c
b/package/network/services/hostapd/src/src/ap/ubus.c
index 367e1b652b..30bb353953 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.c
+++ b/package/network/services/hostapd/src/src/ap/ubus.c
@@ -1757,3 +1757,36 @@ void hostapd_ubus_notify_radar_detected(struct
hostapd_iface *iface, int frequen
ubus_notify(ctx, >ubus.obj, "radar-detected", b.head, -1);
}
}
+
+void hostapd_ubus_notify_bss_transition_response(
+ struct hostapd_data *hapd, const u8 *addr, u8 dialog_token, u8
status_code,
+ u8 bss_termination_delay, const u8 *target_bssid,
+ const u8 *candidate_list, u16 candidate_list_len)
+{
+#ifdef CONFIG_WNM_AP
+ char *cl_str;
+ u16 i;
+
+ if (!hapd->ubus.obj.has_subscribers)
+ return;
+
+ if (!addr)
+ return;
+
+ blob_buf_init(, 0);
+ blobmsg_add_macaddr(, "address", addr);
+ blobmsg_add_u8(, "dialog-token", dialog_token);
+ blobmsg_add_u8(, "status-code", status_code);
+ blobmsg_add_u8(, "bss-termination-delay", bss_termination_delay);
+ if (target_bssid)
+ blobmsg_add_macaddr(, "target-bssid", target_bssid);
+ if (candidate_list_len > 0) {
+ cl_str = blobmsg_alloc_string_buffer(, "candidate-list",
candidate_list_len * 2 + 1);
+ for (i = 0; i < candidate_list_len; i++)
+ snprintf(_str[i*2], 3, "%02X", candidate_list[i]);
+ blobmsg_add_string_buffer();
+ }
+
+ ubus_notify(ctx, >ubus.obj, "bss-transition-response", b.head,
-1);
+#endif
+}
diff --git a/package/network/services/hostapd/src/src/ap/ubus.h
b/package/network/services/hostapd/src/src/ap/ubus.h
index acdac74360..899b001dd5 100644
--- a/package/network/services/hostapd/src/src/ap/ubus.h
+++ b/package/network/services/hostapd/src/src/ap/ubus.h
@@ -55,6 +55,10 @@ void hostapd_ubus_notify_beacon_report(struct hostapd_data
*hapd,
void hostapd_ubus_notify_radar_detected(struct hostapd_iface *iface, int
frequency,
int chan_width, int cf1, int cf2);
+void hostapd_ubus_notify_bss_transition_response(
+ struct hostapd_data *hapd, const u8 *addr, u8 dialog_token, u8
status_code,
+ u8 bss_termination_delay, const u8 *target_bssid,
+ const u8 *candidate_list, u16 candidate_list_len);
void hostapd_ubus_add(struct hapd_interfaces *interfaces);
void hostapd_ubus_free(struct hapd_interfaces *interfaces);
@@ -107,6 +111,13 @@ static inline void
hostapd_ubus_notify_radar_detected(struct hostapd_iface *ifac
{
}
+static inline void
Re: Release goals for 22.XX
The below is a fairly prescient analysis of the situation, and a good approach, Rui. I think openwrt will be fine staying put on iptables, until bpfilter matures. I think I have about 20 individual rules on my FW. Having the capability is nice, but most home users probably don't have or need 1 rules on their potatoes. Why not just have one 'big' change for the next major version? Like "we're aiming for all platforms on 5.10". Then if that's done, the focus is on quality. (We're still waiting on ar79 to get DSA patches in during 21.x) Many forum users have shown themselves to be fairly decent testers and guinea-pigs for rc testing. On 2021-10-06 19:42, Rui Salvaterra wrote: Hi, Rich, On Wed, 6 Oct 2021 at 17:54, Rich Brown wrote: Paul, Rafał, I think our emails passed in the ether... (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html) As I said in that message, I am very aware of the time constraints of the volunteers for OpenWrt. And I don't mean to suck the conversation into "grand strategies" without any endpoint. Let's focus on our next step. In my earlier note, I asked: 1) What would prevent us from accomplishing the 22.XX Release Goals in March 2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) - How do we see the time between now and March playing out? - Are there things we should leave out? Or should the release date be shifted? I think the target date is fine, as long as we don't try to bite more than we can chew. :) I'm a bit wary of the firewall4 migration, to be honest. Do we have performance numbers comparing nftables vs iptables, for complex rule sets? I'm asking because nftables can be slower than iptables [1], in at least in some scenarios. I also believe the priority should be to get all targets at 5.10 by default and to drop those which are stuck at 5.4 for some reason (small flash/RAM, unmaintained, etc.). And a dropped target doesn't mean it's gone forever, it can always be revived in the future, with enough interest, talent and Git. :) With this out of the way, bumping mac80211 to 5.15 is probably the hardest task at hand and, after it's done, I think we're release-worthy. Anything else (say, DSA for ath79 targets with qca8k switches) would be a nice bonus, but never a release blocker. Just my 0.02 €. Thoughts? Thanks, Rui [1] https://www.phoronix.com/scan.php?page=news_item=BPFILTER-2021 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On Wed, Oct 6, 2021 at 10:46 AM Rui Salvaterra wrote: > > Hi, Rich, > > On Wed, 6 Oct 2021 at 17:54, Rich Brown wrote: > > > > Paul, Rafał, > > > > I think our emails passed in the ether... > > (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html) > > > > As I said in that message, I am very aware of the time constraints of the > > volunteers for OpenWrt. And I don't mean to suck the conversation into > > "grand strategies" without any endpoint. > > > > Let's focus on our next step. In my earlier note, I asked: > > > > 1) What would prevent us from accomplishing the 22.XX Release Goals in > > March 2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) > > > > - How do we see the time between now and March playing out? > > - Are there things we should leave out? Or should the release date be > > shifted? > > I think the target date is fine, as long as we don't try to bite more > than we can chew. :) > I'm a bit wary of the firewall4 migration, to be honest. Do we have > performance numbers comparing nftables vs iptables, for complex rule > sets? I'm asking because nftables can be slower than iptables [1], in > at least in some scenarios. > > I also believe the priority should be to get all targets at 5.10 by > default and to drop those which are stuck at 5.4 for some reason > (small flash/RAM, unmaintained, etc.). And a dropped target doesn't > mean it's gone forever, it can always be revived in the future, with > enough interest, talent and Git. :) With this out of the way, bumping > mac80211 to 5.15 is probably the hardest task at hand and, after it's > done, I think we're release-worthy. Anything else (say, DSA for ath79 > targets with qca8k switches) would be a nice bonus, but never a > release blocker. As a sidenote, more testers are needed for it. There's also the issue of LED configuration. Colors are not easy to figure out. Some configs are totally bogus as well. > > Just my 0.02 €. Thoughts? > > Thanks, > Rui > > [1] https://www.phoronix.com/scan.php?page=news_item=BPFILTER-2021 > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Hi, Rich, On Wed, 6 Oct 2021 at 17:54, Rich Brown wrote: > > Paul, Rafał, > > I think our emails passed in the ether... > (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html) > > As I said in that message, I am very aware of the time constraints of the > volunteers for OpenWrt. And I don't mean to suck the conversation into "grand > strategies" without any endpoint. > > Let's focus on our next step. In my earlier note, I asked: > > 1) What would prevent us from accomplishing the 22.XX Release Goals in March > 2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) > > - How do we see the time between now and March playing out? > - Are there things we should leave out? Or should the release date be shifted? I think the target date is fine, as long as we don't try to bite more than we can chew. :) I'm a bit wary of the firewall4 migration, to be honest. Do we have performance numbers comparing nftables vs iptables, for complex rule sets? I'm asking because nftables can be slower than iptables [1], in at least in some scenarios. I also believe the priority should be to get all targets at 5.10 by default and to drop those which are stuck at 5.4 for some reason (small flash/RAM, unmaintained, etc.). And a dropped target doesn't mean it's gone forever, it can always be revived in the future, with enough interest, talent and Git. :) With this out of the way, bumping mac80211 to 5.15 is probably the hardest task at hand and, after it's done, I think we're release-worthy. Anything else (say, DSA for ath79 targets with qca8k switches) would be a nice bonus, but never a release blocker. Just my 0.02 €. Thoughts? Thanks, Rui [1] https://www.phoronix.com/scan.php?page=news_item=BPFILTER-2021 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Paul, Rafał, I think our emails passed in the ether... (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html) As I said in that message, I am very aware of the time constraints of the volunteers for OpenWrt. And I don't mean to suck the conversation into "grand strategies" without any endpoint. Let's focus on our next step. In my earlier note, I asked: 1) What would prevent us from accomplishing the 22.XX Release Goals in March 2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) - How do we see the time between now and March playing out? - Are there things we should leave out? Or should the release date be shifted? I would invite everyone to weigh in. Thanks. Rich cc: OpenWrt-adm > On Oct 6, 2021, at 10:14 AM, Paul D wrote: > > > Wise words from the experienced! > > If making a yearly release is unattainable, isn't making point releases more > achievable? Even if it's adding a single commit, point releases send a signal > to the outside world that the project is still active, and e.g. that security > is in focus. Any point release can be done for trivial amendments and GUI > fixes. ( I do not make light of the steps involved in doing a release ). The > idea being that at least these point releases can be done regularly. > > > So the 'yearly' release is unattainable: is this largely due to the amount of > new material that goes into the 'main/master/head' branch that needs to be > picked and normalized and made stable (if that's how I might summarize making > all the platforms behave consistently)? I would be fine without regular > yearly releases. nightlies are available etc. > > > > On 2021-10-06 07:58, Rafał Miłecki wrote: >> On 30.09.2021 03:34, Rich Brown wrote: >>> My desire would be to name our next release "22.03", with a target release >>> date in March 2022. And we should name the following release "22.09" with a >>> release date in September. And so on - every six months (or whatever >>> interval we believe we can sustain for the long term.) >> This is absolutely undoable. We have too little manpower and too little >> people actually interested in preparing releases. It takes testing, >> checking feedback, reviewing bug reports, debugging issues, backporting >> changes. That is a lot of work. >> Every time we have a discussion about releases there comes an idea of >> time-based releases. Also a lot of people have opinions on when to >> branch and how to proceed with development. >> When it comes to actually working on a release there are very people >> that stay involved. >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Wise words from the experienced! If making a yearly release is unattainable, isn't making point releases more achievable? Even if it's adding a single commit, point releases send a signal to the outside world that the project is still active, and e.g. that security is in focus. Any point release can be done for trivial amendments and GUI fixes. ( I do not make light of the steps involved in doing a release ). The idea being that at least these point releases can be done regularly. So the 'yearly' release is unattainable: is this largely due to the amount of new material that goes into the 'main/master/head' branch that needs to be picked and normalized and made stable (if that's how I might summarize making all the platforms behave consistently)? I would be fine without regular yearly releases. nightlies are available etc. On 2021-10-06 07:58, Rafał Miłecki wrote: On 30.09.2021 03:34, Rich Brown wrote: My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in September. And so on - every six months (or whatever interval we believe we can sustain for the long term.) This is absolutely undoable. We have too little manpower and too little people actually interested in preparing releases. It takes testing, checking feedback, reviewing bug reports, debugging issues, backporting changes. That is a lot of work. Every time we have a discussion about releases there comes an idea of time-based releases. Also a lot of people have opinions on when to branch and how to proceed with development. When it comes to actually working on a release there are very people that stay involved. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Suggestion: Explicitly warn to not use GitHub web UI for patches
On 2021-10-05 21:17, Rich Brown wrote: On Oct 5, 2021, at 10:24 AM, Paul D wrote: Write this up into an FAQ/howto on openwrt.org (this is, after all, the OWRT way) Yes, it's always more powerful (and useful) to tell people what TO do, instead of what NOT to do. I contribute very occasionally, and by trial and error, I *think* I have found the procedure. (And if it's not right, or not optimal, I would be delighted to learn how to do it better...) - In Github, fork the official repo into my personal Github account - Clone my personal copy of the repo to my laptop - Create a branch for my changes on my laptop - Monkey around, improve the world, then... - Squash my commits so that there's only one change (optional, but it tends to improve the commit messages) - Push my commits back to my personal repo - From my personal Github account, create a PR for my branch back to the official OpenWrt repo Do I have the gist of it? Many thanks. Rich Yeah, that's roughly my SOP. -fork repo -clone -edit -commit -push (--force) to my clone -PR with optional: -add remote: original repo -pull -rebase -commit --amend -push --force ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
> On Oct 6, 2021, at 1:58 AM, Rafał Miłecki wrote: > > On 30.09.2021 03:34, Rich Brown wrote: >> My desire would be to name our next release "22.03", with a target release >> date in March 2022. And we should name the following release "22.09" with a >> release date in September. And so on - every six months (or whatever >> interval we believe we can sustain for the long term.) > > This is absolutely undoable. We have too little manpower and too little > people actually interested in preparing releases. It takes testing, > checking feedback, reviewing bug reports, debugging issues, backporting > changes. That is a lot of work. > > Every time we have a discussion about releases there comes an idea of > time-based releases. Also a lot of people have opinions on when to > branch and how to proceed with development. > > When it comes to actually working on a release there are very people > that stay involved. I am so pleased that you are pushing back against my suggestion, especially since you are actually *doing* the work. (I have not, and probably will never contribute any code to OpenWrt. But I've been writing software for 40 years, and have watched a lot of projects struggle with their goals.) I advocate for regular releases because: - It keeps the project fresh. We look like a "living project" and attract new users and new developers - Our users get new features in stable versions on a regular basis - It gives our users confidence in us - It makes us proud to ship software BUT... you point out the very real problem - limited available time for people who can actually do the work. This leads me to think about how we can preserve our most precious resources - time and attention. Some questions: 1) What would prevent us from accomplishing the 22.XX Release Goals in March 2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) - How do we see the time between now and March playing out? - Are there things we should leave out? Or should the release date be shifted? 2) How important is it to update kernels regularly? In the abstract, I know there's a balance between backporting critical bug fixes and important features to the current (older) kernel vs the effort to move (and test) our entire code base to a new kernel. - But what real-world implications does this have for OpenWrt? - What's the balance (in time/effort) between those two activities? - How do we balance the *value* of new kernel features vs what we could create if we spent the time on other projects? 3) Architecture support. There's a certain amount of pride that "OpenWrt runs just about everywhere". (I agree - this is an astonishing accomplishment.) But... now the attention from skilled developers is scarce. - Does support of this broad variety of architectures add to the developer effort? - Should we ever drop architectures from support? - How would we decided to do this? - Can we make a "guesstimate" of how much time we'd save if we drop architectures? 4) How quickly should we embrace new devices? In the forum, and to a certain extent on openwrt-devel, I see notes like "Hey, I just found this sexy device quad-core device with 128M Flash and 512M RAM. And it's only US$17! Can you make OpenWrt run on it?" - Does a task like this take any effort from "core developers"? - Does a task like this increase our testing effort? - Does a task like this create an on-going maintenance/support obligation? - If so, do we need a process to decide whether to take on a new device? 5) I am fully aware that OpenWrt is driven by volunteers. We contribute because a particular piece of the puzzle seems interesting or fun. We can't "force" anyone to do anything. - How can we construct OpenWrt goals (kernel, packages, releases, documentation, build system, all of it...) to match projects that excite our group? - What would it mean to attract new people to "fill in the gaps" of our project. I don't imagine that we'll come with answers to all these on the mailing list. Perhaps Hauke will add them to the next online meeting. Thanks for listening. Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt imx split status?
On 05.10.21 17:42, Piotr Dymacz wrote: Hi Tim, On 04.10.2021 00:22, Tim Harvey wrote: Piotr, How is your progress regarding submitting patches to OpenWrt to split the imx target into multiple arch related subtargets (like cortexa7, cortexa9)? I'm planning to clean it up and send patches this week. I finally got final revision of the hardware I was working on that for. Hi Piotr, I've got this patch [1] lingering in my staging. Is it still applicable after your patches? Feel free to take it and include it in your series. [1] https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=e678ae29e06b2feee81095da53a472652fba4f7c Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 30.09.2021 03:34, Rich Brown wrote: My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in September. And so on - every six months (or whatever interval we believe we can sustain for the long term.) This is absolutely undoable. We have too little manpower and too little people actually interested in preparing releases. It takes testing, checking feedback, reviewing bug reports, debugging issues, backporting changes. That is a lot of work. Every time we have a discussion about releases there comes an idea of time-based releases. Also a lot of people have opinions on when to branch and how to proceed with development. When it comes to actually working on a release there are very people that stay involved. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
