Thank you Thomas for your suggestion, we already did exactly that and now
even have a CI verification for PR's to this branches in a public fork. The
main problem mentioned by Pedro already is that the changes we are doing
are already big and they are not going to be smaller over time. The merge
The problem is that the process of porting is incremental and requires
several patches from different collaborators to advance in different areas,
like build system, infrastructure, code fixes, virtualization This gets
difficult when having multiple scattered PRs open. We lost track of which
Hi Pedro,
Is there a problem in working off a branch in your own fork and issue a
[WIP] PR ? This is a pattern I have seen a lot and personally I think it
works well, since it also gives some visibility if someone is interested in
looking at the progress of the work. You can add people
Thanks a lot for creating these branches and proposing the idea, for the
reasons you listed.
We tried during this week to work with these branches with @lebeg for
Android and Arm support, for the reasons listed below these branches are
not useful for us, so you can delete them.
1. We don't
The problem with regular reviews here is that we might want to keep
temporary code or hacks as a temporary solution before we finalize it. A
regular review would have problems with that.
The reason against a fork is the requirement of CI. Since multiple people
are working on the same branch and
Hello,
we are currently revisiting our setup for ARM and Android. Since we're not
in a stable state but need some way to collaborate while having support
from CI, we proposed the usage of feature branches. Thus, I have create the
two branches devel-arm and devel-android into which Anton and Pedro
