Split GitHub repos

[philclifford]

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]

This look like an interesting idea.

[philclifford]

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)

[philclifford]

[philclifford]

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]

Rebased to fix conflicts. Needs to wait on further fixes and contributions being merged and then another conflict resolution then squashing....

Github packages
01-main
57
-----------
02-main
50
-----------
03-main
33
-----------
PPA packages
01-main
35
-----------
02-main
0
-----------
03-main
1
-----------
non-Github packages
01-main
166
-----------
02-main
0
-----------
03-main
1
-----------
Total packages : 312
-----------

[flexiondotorg]

Please rebase, I'll try to make sure I get this before before other changes next time.

[philclifford]

Rebased, deconflicted and nearly ready to review.
Don't worry about breaking this by merging fixes or contributions ahead of it. I'd much rather get fixed package definitions (or contributions) out there than hold them up for this. It would be better I think for me to merge in the PPA split (philclifford#9) first anyway if that seems a good idea.
Setting this draft again as there's work to do on per-repo README.md cogging. Also I think before throwing this at users it needs documenting to some extent, and it would be good to have some functionality for users to disable/enable repos and search/examine where packages have moved/become disabled.