search

GloDroidCommunity / raspberry-pi

Android 14 for the Raspberry PI 4 series based on the GloDroid project
Apache License 2.0
28 stars 5 forks source link

Various improvements #12

Closed rsglobal closed 1 year ago

rsglobal commented 1 year ago

@mikegapinski ,

After this PR lands, I will apply most of the configuration patches to the mainline. After that, we can remove them from this repo.

mikegapinski commented 1 year ago

@mikegapinski ,

After this PR lands, I will apply most of the configuration patches to the mainline. After that, we can remove them from this repo.

@rsglobal

Maybe we should implement some sort of a low for patches that are supposed to land in the configuration upstream? Removing them from device repos just to apply them to the main repository all the time is not exactly efficient.

How it could be done if someone adds a PR to GloDroidCommunity without identifying generic patches that could go upstream:

  1. Create a PR in GloDroidCommunity/device_xxx
  2. Proceed with review, check if patches from patches-aosp/glodroid/_upstream_repo_name are device specific.
  3. If patches are determined to be generic ask the submitter to create a PR in Glodroid with those patches. Close the PR in GloDroidCommunity after the changes reviewed and upstream dependencies are merged.

How I would prefer to submit those PRs:

  1. Create a PR in GloDroidCommunity/device_xxx
  2. Create a PR in upstream with patches that are not device specific
  3. Reference the upstream PR in the GloDroidCommunity PR
  4. Review and merge PR upstream
  5. When upstream is merged GloDroidCommunity PR can be reviewed/merged. If the patches previously submitted to upstream can't be merged there(we determine they are device specific) add them to patches-aosp

Side note: If we create patches that are generic(like the one I did with expanding the userdata partition) they should be only submitted upstream, the only thing required in GloDroidCommunity/device_xxx is a PR with the updated manifest ref

rsglobal commented 1 year ago

My concern is that any complex flows will slow down the progress. Also, the current approach allows for creating releases of the particular device more frequently without worrying about breaking generic code. Currently, I'm applying these generic patches to the pinephone, and once confirmed they work well not only for rpi4, will push them into glodroid/configuration.

I'm ok with enforcing some laws, but let's give us some time to collaborate without them to summarize what can be improved by the laws, so the latter will help, not hurt.

mikegapinski commented 1 year ago

Sure, I am just a process optimisation freak.

I forgot about the fact that devices are released independently at the moment, it would make sense to revisit what I suggested once more boards show up as those generic patches have to be verified on a few of them once they hit the upstream

rsglobal commented 1 year ago

CI with auto-deployment and testing may help a lot here. But such a CI is yet one big project.