Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split GitHub repos #1000

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

philclifford
Copy link
Member

@philclifford philclifford commented Feb 9, 2024

Move some github-sourced apps into extra repositories that can be disabled by default.

Arbitrary split into 3 for now. 01-main should be updateable ~ hourly without an API key if 02 and 03 are disabled.

For now user must manually deal with the 3 repos.

Options might be to add switch to --repos-only.

Todos ??

  • decide if initial split keeps all 3 live to start - it must
  • maybe if in first update we initialize 2 and 3 we should call another update --repos-only
  • Confirm split strategy
  • Handle notification of installed app having moved
  • Provide functionality to
    • enable/disable repos
    • list disabled repos contents (as part of above and/or separately)
    • search app optionally in disabled repos too

@flexiondotorg
Copy link
Member

This look like an interesting idea.

deb-get Outdated Show resolved Hide resolved
@philclifford
Copy link
Member Author

philclifford commented May 8, 2024

I'll need to revisit this to rebase the split from a current head. Probably best to do that after a release and before adding or amending package definitions if possible. Done. A little fiddly but not as bad as it might have been.

And there are some other bits to decide and implement if this is to progress (see below) so it should wait until after a release. As a proof of concept though this worked quite well and has some benefits. It also raises issues around

  • deciding how to split / what to put into 02- 03- ...
  • whether / how to label the 02- 03- ... sections : on the one hand we don't want to be disrespecting upstreams by implying their app is "down in tier 3" but on the other we could have "featured" (01) "essential" (02) ... "alternative", "non-free" ....
  • Where should contributors' future PRs add new packages ?
  • Should one aspect of the split be "by source" so that splits are not just about github convenience but could also, for example, group PPAs and only enable default enable them for Ubuntus (and make it easy for a user to configure "no PPAs for me" or whatever freedom they desire. ( see feat: move PPA sourced packaged to new 04-main repo philclifford/deb-get#9 )
  • Do we do the "contribution guidance update and enforcement" thing first or the split or both together? (Clearly for the users "one" coordinated "breaking change" would be better)

deb-get Outdated Show resolved Hide resolved
@philclifford
Copy link
Member Author

philclifford commented May 8, 2024

image

deb-get Outdated Show resolved Hide resolved
@philclifford philclifford marked this pull request as ready for review May 14, 2024 19:02
@philclifford philclifford marked this pull request as draft May 14, 2024 19:13
@philclifford
Copy link
Member Author

with ppas moved :

Github packages
01-main
58
-----------
02-main
52
-----------
03-main
33
-----------
04-main
0
-----------
PPA packages
01-main
0
-----------
02-main
0
-----------
03-main
0
-----------
04-main
38
-----------
non-Github packages
01-main
132
-----------
02-main
0
-----------
03-main
0
-----------
04-main
38
-----------

@philclifford philclifford marked this pull request as ready for review May 14, 2024 22:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants