Repository navigation
Stripping the release tarballs #5618
Description
Activity
yes for cleaning more, not so much for a separate readme because of the extremely low visibility it'll have for all of us which will lead to an increased likelihood that it'll quickly become stale and outdated
+1 clean more
Instead of an alternate
README, is there any enthusiasm for putting the build instructions in aBUILD.mdand linking to it from theREADME.mdfile? We could keep minimal build instructions for the most popular platforms in theREADME(or not). Of course, theREADMEwould have a link to the build instructions document.It seems to me that the build instructions dominate the
README. Maybe that's fine, but maybe we'd rather have a more focused message there.CLARIFICATION: So instead of stripping build stuff out of an alternate README, strip it out of the canonical README and have the build instructions live in its own document. So we still only have one README and one place where build instructions live.
PR here: #5695
- added a commit that references this issue
on Mar 16, 2016
(refs #5612)
I think we should be a bit more aggressive as to what we bundle in the release tarballs. I see it similar to how autotools handles
make distversus using the original repo; meaning most files there for specific development won't be included - but enough files to verify the state of the binary often is (read: test suite). With this strategy most dotfiles, readme's in the root directory would go away. Additionally, I'd suggest stripping everything related to linting and introduce some minor logic inMakefile/vcbuild.batthat points people togit cloneif they want to do development. Theres probably a few more things intools/we could strip, such as packagemaker-stuff.Finally, @bnoordhuis suggested we bake an alternate readme that we push as part of the release packages that more accurately represents whats included and how to use it.
Thoughts? Anything else that should go?
cc: @nodejs/build, @bnoordhuis, @Trott, @jasnell