Purpose of openwrt-devel?

[Elliott Mitchell]

On Tue, Mar 12, 2024 at 09:11:23PM -0700, Elliott Mitchell wrote:
> On Wed, Mar 13, 2024 at 01:55:07AM +0100, Robert Marko wrote:
> > On Wed, 13 Mar 2024 at 01:36, Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
> > >
> > > 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.
> 
> Fascinating.
> 
> The original technique, which does not require scripting was suggested
> Tue Oct 24 05:05:25 PDT 2023.  Scripting isn't necessary.  Scripting is a
> good idea since it would be done on a regular basis.
> 
> https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041672.html

Stating this explicitly, the procedure can be done manually.  The
approach appeared to have concensus in October, while 8a9273d51e was
originally done in January.  Yet the pull and 8a9273d51e ignored this.

Also needs to be stated, these don't survive rebasing.  Rebasing won't
preserve the merges and will thus loses the history on the old versions
(better than losing it on the newer ones, but still...).

Given the number of pulls which already miss the use, doing all boards at
the same time really does seem the way to go.


-- 
(\___(\___(\______          --=> 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