On Tue, 25 Feb 2020 13:54:41 +0100 doak <[email protected]> wrote:
> Hi Denis and all,
Hi,
First keep in mind that I'm not used to merges, so feel free to correct
me if anything in this mail inaccurate.
Background:
-----------
The thing here is that there are different uses cases that are somewhat
mixed together, so I'll add more background on that as this is required
to have a system that doesn't stand in the way of people working on
Replicant.
So, we have the (complete?) source code for all the Replicant versions,
starting from Android 1.5.
If we want to go as far as possible with the devices that are still
supported by Replicant 6.0, it brings us to the Replicant 4.0 0001
release, with the Galaxy SII (GT-I9100) and the Galaxy Nexus (GT-I9250).
If we want to go further, assuming that we find ways to build the
source code, we probably all lack the devices for Replicant 2.3 to do
runtime testing.
I've managed to build Replicant 4.2 recentl with a Trisquel 7 LXC
system vm, in libvirt.
So while Trisquel 7 is not supported anymore it's still possible to
build Replicant 4.2 to do regression tracking, and it was used to do
that.
I didn't try building Replicant 4.0 as I didn't need to yet, but I may
still need to do it in the future if I need to understand better the
RIL<->libsamsung-ril API versioning, in the case it makes sense to
understand to care in some way or another about support for older RIL
versions, like if we need to make sure it continue to work or if we
need to remove the code for older RIL versions.
If the maintenance is minimal, it might also be a good idea to keep the
compatibility as we never know if other projects manage to implement
some of the (old) RIL API.
In any case to build ancient Replicant versions, we also need Trisquel
to keep its old repositories online, so we can still install the old
versions to build Replicant.
If we want to go earlier, up to Replicant 2.3, all current Replicant
contributors probably lack any of the supported devices. I didn't see
anybody with a Nexus S or a Galaxy S on the People wiki page for
instance.
So even if libsamsung-ipc was already there at the time, testing things
at runtime would probably be complicated and not worth the time and
effort.
As for Replicant 2.2 and before are probably not interesting beside for
historical purposes as the code to support the hardware is very
different from the one we have now. For instance the devices didn't
even use libsamsung-ipc.
So if I forget about the versions that have devices that are not
supported anymore, we have:
+-----------+----------------+
| Replicant | |
| Version | base |
+-----------+----------------+
| 4.0 | CyanogenMod 9 |
| 4.2 | CyanogenMod 10 |
| 6.0 | LineageOS 13 |
+-----------+----------------+
The issue is that even if the base distribution was mostly the same
between theses version, AOSP and the code itself did change a lot.
So in practice between CyanogenMod 10 and LineageOS 13, there is a lot
of changes in the repositories.
I would need to do some research to know it for sure but I also suspect
that the history of some git repositories are either totally different
or diverge from very early on, from one version to the other.
Here's how it looks line in practice with merges (which were done
before I started rebasing):
[CyanogenMod 9 history] -> [Replicant 4.0]
| |
| |
v v
[CyanogenMod 10 history] -> [Replicant 4.2]
| |
| |
v v
[LineageOS 13 history] -> [Replicant 6.0]
To merge two Replicant versions (like 6.0 and 4.2) some big adaptation
merge commit is typically done.
This means that before that commit, it's not easy to go back in time.
Since everything is tied together in that commit it's not easy to
rebase it before in repositories like vendor/replicant.
So you end up being able to bisect since that big merge commit until
the big jump to the next Replicant version.
In addition to that we need to make sure to keep many repositories
in sync to even build the source code. There are some cases where we
can manage to support different Android versions with the same code
like with libsamsung-ril and libsamsung-ipc but it's typically not the
case for many repositories like the hardware/ of framework/ ones.
As we look at the repository sync from the Replicant point of view,
what is in git constitute the actual Replicant code in use, so if we
have bugs there it's a Replicant bug that is usually fixed or
documented somehow.
If we go outside of the Replicant versions (like after Replicant 4.2
but before the Replicant 6.0 merge) we also have to deal with that and
it's already time consuming to deal with it in Replicant, so we'd have
to do it for many many revisions.
Bisecting things on pure upstream repositories (LineageOS) may
not be easy either, as I suspect that they rewrite the history
sometimes, but I don't have an example off hand.
I've no idea if AOSP is better in that regard or where this issue comes
from, assuming that it really exists and that I didn't make confusions
with other things and that my memory is good on that.
> > [...] we started considering to
> > always rebase on top of LineageOS because, as we were told, they
> > merge security fixes, and they also continue to do it even way
> > after Android Open Source project stopped to do it.
>
> What is the benefit of a rebase in that case? Can't you just merge
> that as well? In fact it should be a ff-merge as long we didn't
> changed anything.
>
> I like rebase very well, but only in cases where I intentionally want
> to *change history* like
> * rephrasing commit messages.
> * restructuring/reordering commits.
> * fixing commits.
This is what I've done in many case, where the commits are fixed to be
applied on top, or removed if they were merged etc.
This enable not to care about Replicant 4.0 and 4.2 when you just want
to know what's changed for Replicant 6.0 to port it to Replicant 9 for
instance.
Some commits are also sometimes merged upstream, so we can drop these.
Having a clear view of the changes help a lot during development, for
instance we were able to bring fast graphics on Android 9 thanks to
rebases and to dllud and GrimKriegor's work.
If the repository rebases automatically, using the command you gave does
the same thing with less work from my side.
When I managed to rebase the Replicant changes, changing the commits to
be adapted to the LineageOS changes, and that at the end there is no
diff between the merged history (with a big merge commit) and the
rebased history, do you know if it's possible to merge both
histories somehow and make the old merge history point to the rebased
history in something that would look like that:
[lineageos]->[replicant changes]->[old big merge commit]
|
|
v
[new merge commit without diff]
|
|
v
[more recent lineageos history]->[rebased replicant changes]
Also note I have a hard time picturing how and when to use merges given
the big diff with different Android versions, but that might also be
because I'm not used to merges.
The other issue would be to find a way to keep track of all that in
git. When the rebase its possible and automatic, it would be nice
to make it obvious in git and not having to refer to the wiki or run
the git rebase command each time you are in a git repository.
So merging rebases and merges could be done there too, assuming it
somehow still makes sense to have rebase in these cases, as I might
change my mind on that with this discussion.
> >> The issue is that with merge commits it then becomes very hard and
> >> time consuming to understand what really constitutes Replicant
> >> changes, so I think that rebases are better.
> This seems to be a quite important aspect. What about the mentioned
> command? Does it not work?
It does work, I've tried it in different scenarios and I didn't find
big issues yet. When the rebase can be done automatically, it seems to
do the job.
When not, it probably shows the commits, and as some of the information
is in the big merge commit, it becomes messy to understand and you have
not only to look at the commit, and the merge commit, but understand
what changes are needed between Android versions.
In my opinion when it's the case, it's better to rebase, because even
if it takes a bit more time than doing the work of understanding the
changes in your head, that work is done only once, and also benefits
other contributors.
> >> In short: Is there any way to show that diffs in the web frontend
> >> of Git? [...]
> > cgit seems to support that:
> > https://git.replicant.us/contrib/GNUtoo/hardware_replicant_libsamsung-ipc/commit/?id=c137579d09b0de9a903bd764bb0cb8196190dff3
> >
>
> Not exactly what I was looking for. I meant a diff for arbitrary
> revisions. This matches a plain 'git show <rev>'.
I've found a way to do it by looking in cgit's source code:
https://git.replicant.us/replicant/vendor_replicant/diff/?id=replicant-6.0-0001&id2=replicant-6.0-0004-rc1
However I don't know how to construct such URL from the web user
interface.
Denis.
pgplrTnR9kA0X.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
