RFC: Organizing a Unison namespace

unisonweb / unison

A friendly programming language from the future

https://unison-lang.org

Other

5.75k stars 269 forks source link

RFC: Organizing a Unison namespace #1409

Open pchiusano opened 4 years ago

pchiusano commented 4 years ago

Thread to collect ideas and feedback on: https://www.unisonweb.org/docs/codebase-organization

Questions:

Are the conventions straightforward to follow?
Have you encountered any paper cuts or awkwardness using these conventions?
Is there some UCM command support that might make it easier to follow these conventions?
Overall feedback: what do you think?
Got any ideas for improvement?

aryairani commented 4 years ago

Neat!

If you are proposing the PR for an external codebase (not what's in trunk), you can use the pull-request command to propose the change. See helow [sic].

an external codebase (not what's in trunk) <--

I don't follow this phrase, what does it refer to?

How to create a release

Maybe a note about double-checking your patch before publishing?

A little delirious here, but looks great!

atacratic commented 4 years ago

Yeah, looks awesome! I feel like I'm really getting a sense for how it all fits together now.

Nits:

typos, search for "gitub" and "patches to. your"
In the 'Day to day' section, under 1 'If you're the sole maintainer', the 'You can alternately do the merge in a staging namespace with:' steps should I think be extended to show going from the staging namespace to trunk, so that it does actually add up to an alternative to the direct-to-trunk variant.

pchiusano commented 4 years ago

@atacratic and @aryairani thanks for giving it a look. I think I got all those edits, then published the draft on the site https://github.com/unisonweb/unison/issues/1409#issue-596294100 with a note at the top that it's a draft and directing folks here to give additional feedback. There's a whole new section on patch management as well that gives guidance on how to keep your release patch clean. /cc @anovstrup and @pete-ts

aryairani commented 4 years ago

@pchiusano Awesome!

The update and replace.term and replace.type commands also take an optional patch name, if you want to build up a patch somewhere other than the default patch. This is handy for keeping logically unrelated patches separate. You can also move.patch and delete.patch.

todo and patch also take an optional patch name (though it's not reflected in the help for patch).

aryairani commented 4 years ago

Should we close this?