Purpose of openwrt-devel?

[Robert Marko]

On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
>
> Well, what purpose does the openwrt-devel mailing list serve?
>
> As near as I can tell it looks suspiciously like it is a method to divert
> developers from where everything is done.  There isn't too much review
> activity.  Anything which does get a positive review tends to simply
> disappear unless it is later resubmitted via GitHub.
>
> According to https://openwrt.org/submitting-patches patch submission via
> GitHub or the openwrt-devel mailing list can be done.  The amount of text
> seems to suggest the mailing list is preferred.  Yet, can anyone cite a
> single patch which was sent to the mailing list, reviewed positively and
> brought into the main branch without resubmitting via GitHub?

Hi Elliot,

Both methods of submitting changes are accepted.
However its is correct that most action happens via GH, that is the
way that most
users are more comfortable sending their changes and honestly for me
its much easier
to review and request changes and we have CI integrated as well.

>
> Then there is technical discussion.
>
> A rather serious problem with how kernel version changes are handled was
> brought up.  This eventually lead to:
> https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html
> Which seemed to gain a consensus of being the best solution to the
> problem.
>
> Due to this not being the easiest process to implement, I went and
> created a script for automating the process:
> https://lists.openwrt.org/pipermail/openwrt-devel/2024-February/042254.html
> While some negotiation was expected, nothing has happened.  I was
> expecting to need some adjustment to match other's development
> environments, yet no problems have been found.
>
> Yet now, 8a9273d51e simply throws the consensus in the garbage.  Why was
> something which there was consensus on ignored?  Perhaps this mailing
> list is now >99% ignored and people should no longer be directed here?

It is not ignored, it was just a case where kernel 6.6 support was already done
by the time we merged the kernel bump script that does the GIT magic to
preserve the history and with multiple people working on 6.6 target support
based of the same PR it was not practical to stall it any further.

I expect further kernel bumps, both generic and target ones will use the script
and preserve history but it will take some time to get everybody
familiar with it.

>
> If action is taken quickly, the breakage in 8a9273d51e might be mostly
> fixed.  Check out 71360660e6, use the script to do an update and check
> out the result.  Then run `git merge --no-commit main` and then run
> `git commit --amend`.  I *think* this should generate the correct
> result (squashing two merge commits together, creating a 3-way merge).
>

We cannot really change GIT history at this point I am afraid.

Regards,
Robert

> Yet in the end, does this mailing list continue to serve any purpose
> what-so-ever?  Perhaps I should just give up and opt for Alpine instead.
>
>
> --
> (\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
>  \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
>   \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>
>