-
Notifications
You must be signed in to change notification settings - Fork 0
The great GitHub migration #3
-
We've been given the green light to move the Topiary repository from the Tweag GitHub organisation to this new Topiary organisation, providing we maintain appropriate Tweag branding (e.g., in the README).
As far as branding is concerned, this is a triviality, so its discussion isn't necessary. (Moreover, Tweag branding already exists in the Topiary organisation's README, so we've already partially satisfied this.)
It occurs to me that this could be a worthwhile opportunity to breakup the Topiary monorepo to a certain extent. There are a few components which should probably not be in there; namely the playground and the website (and, perhaps, even the documentation/book). There is also topiary-opam (@Niols).
To dogfood the BUD process, let's initiate the discussion on what is and isn't in scope. Discussion points:
-
Should we migrate
tweag/topiarytotopiary/topiaryat all?Pros: Better discoverability; Topiary becomes a "first class" citizen, in a sense
Cons: Indirect link back to Tweag; Everyone has to update their remotes; Non-trivial process -
If we migrate, which, if any, subcomponents should we break out of the monorepo in to their own repositories?
- Topiary website?
- Topiary playground?
- Topiary Book and/or manpages?
- Others?
-
Open questions, if we migrate:
- Should
topiary-opamalso be migrated and what changes are required, if done so? - Can we still use the Tweag Cachix account?
- The website deployment will necessarily change, whether it's broken out from the monorepo or otherwise. I suspect this will just need a DNS change against
topiary.tweag.ioand appropriate GitHub Pages configuration, but I'm not completely sure! This isn't really a question...so, does anyone have any better ideas about this?
- Should
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 2 comments
-
Cons: [...] Everyone has to update their remotes; Non-trivial process
Not really, tweag/topiary will continue working as a remote as long as we don't create a new repository there.
Migrating sounds reasonable to me.
If we migrate, which, if any, subcomponents should we break out of the monorepo in to their own repositories?
I can't comment on the specific components. But the two benchmarks that I would apply are:
- Are these two things modified together often? Typically, if modifying one requires modifying the other (not necessarily symmetrically), then the two components should probably be in the same repository. Conversely, if the master branch of X can depend on a release of Y, they should probably be two separate repositories.
- Are they released independently? Does it make sense to release these components at different times (e.g. a website may cover several repositories and be updated if any of them are updated, maybe), then it makes sense to have them as separate repositories. But if they are always released together, they probably aren't different projects enough to warrant separate repositories.
Can we still use the Tweag Cachix account?
Yes, that's fine.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1