Hi Patrick,
Am 16.06.2018 um 01:18 schrieb patrick patrick@wylight.de:
On 15.06.2018 17:42, H. Nikolaus Schaller wrote:
Am 15.06.2018 um 00:36 schrieb patrick patrick@wylight.de:
So this was a good point in time rebase and fix and extend the code. But then we did leave it as is. Especially because the config system was in the middle of being upgraded and there were experiments with device tree in u-boot. So we decided to "never touch a running system".
That's an interesting topic to discus, because my opinion is quite the
opposite. But I don't want to start an argument on my second day on this list so let's keep that discussion for the release party and in the mean time I try to persuade by action.
Yes, let's do it!
My argument is not a technical one but an organizational one... Or weighting usefulness vs. efforts.
And there I see that rebasing u-boot to every new release from upstream doesn't add many significant features, but takes a lot of testing time.
Therefore, if we wait until a big set of new features have accumulated and then do the rebase and testing once, it is a much better improvement for the invested time.
For the kernel I see the reverse situation. Every new release brings significant improvements - either from upstream or by our own work to fill gaps (e.g. missing device drivers). For U-Boot we have almost no missing features because it does what it is designed for.
Therefore for the kernel, the rolling rebase scheme has turned out to be better manageable than taking a snapshot, develop and fix missing things the next years. But not be able to rebase it to a newer kernel because kernel APIs have diverged too much.
Any my final though is that u-boot belongs to the basis we want to build something on. So it should be stabilized - but not changed too often...
Where I see the next good situation for upgrading u-boot source code is when there is no longer a (horrible) mixture of old u-boot config and Kconfig where it sometimes needs experimentation to find out what should be configured where. I don't know how the status of 2018.05 is but 2017 u-boot wasn't much better than 2016.
if you need write access at some point, please contact me.
or github
git://git.goldelico.com/gta04-uboot.git is mirrored to https://github.com/goldelico/gta04-uboot
I have a compiling tree, now. I am pretty sure it won't boot, but at least the compiler is happy.
I tried to login/register on https://dev.pyra-handheld.com but didn't got a mail till, now.
So I forked your repo on github and pushed a new branch with my rebase: https://github.com/bruenn/gta04-uboot/tree/v2018.05-pyra-v1
Nice. If I find time, I'll take a look into it.
Maybe we should pull it into http://git.goldelico.com/?p=gta04-uboot.git;a=heads so that it shows up as
letux-2018.05
or alternatively as
work/patrick/letux-2018.05
and give you write access so that you can simply push.
For getting access, please register to http://projects.goldelico.com/p/gta04-uboot/ provide your public key in the user's settings and I can add you to the "Happy Crew" which gives you write access to the git repo.
BR and thanks, Nikolaus