Purpose of openwrt-devel?

[Chuanhong Guo]

On Sat, Mar 16, 2024 at 11:51 AM Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
>
> 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.

If that's the case, the approach isn't practical. Kernel bump can be quite
a heavy task and it usually takes a long time for reviewing and testing,
during which a rebase is unavoidable. Also, we currently apply every
patches and pull requests by rebasing instead of a real merge, so
the merge to preserve history on  the old version will get dropped
anyway.

> 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...).

I think that's OK. We never add a kernel version newer than the one used
in the next stable release before branching off, so the history of the old
versions live in the stable branches.

Maybe we should just drop all the git magic for the history of old versions,
and make the kernel_bump script do a commit for git mv and another one
for copying it back.

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

That won't work. Kernel bumps are contributed by random person who
own the device and have the skill to do so. Nobody is responsible for
taking care of a specific target, and it's impratical to wait for submissions
of all targets and merge it at once.
We can advise the use of the script in the open PRs, but as I mentioned
above, the magic will be wiped by unavoidable rebases.

-- 
Regards,
Chuanhong Guo