Purpose of openwrt-devel?

[Elliott Mitchell]

On Sat, Mar 16, 2024 at 01:47:38PM +0800, Chuanhong Guo wrote:
> 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.

This wasn't why I took the approach, but this suggests the approach used
by my script is the right one.  When it is time to update generic for the
new kernel, have a maintainer run the script.  All devices simultaneously
get new configurations which are copies of their previous ones.

After this point updates happen to both old and new configurations to
keep them synchronized.  As long as they remain identical they don't use
any additional space in Git.  Git doesn't store file/directory
timestamps, so if they're identical their hashes are identical and they
reference the same object.

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

I think this is suboptimal, but vastly superior to completely losing
history.

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

Is having exact duplicate copies of the configurations a problem?  If the
answer to that is "no" then simply create duplicate configurations at
the same time and they don't diverge until the new version is ready.


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