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

Stripping the release tarballs #5618

Closed
jbergstroem opened this issue Mar 9, 2016 · 5 comments

Comments

Projects
None yet
6 participants
@jbergstroem
Copy link
Member

commented Mar 9, 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 dist versus 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 in Makefile/vcbuild.bat that points people to git clone if they want to do development. Theres probably a few more things in tools/ 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

@mscdex mscdex added the build label Mar 9, 2016

@rvagg

This comment has been minimized.

Copy link
Member

commented Mar 9, 2016

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

@Fishrock123

This comment has been minimized.

Copy link
Member

commented Mar 9, 2016

+1 clean more

@jasnell

This comment has been minimized.

Copy link
Member

commented Mar 9, 2016

+1 on cleaning things up. Agree with @rvagg's comments on the readme... I'd just leave that one as is.

@Trott

This comment has been minimized.

Copy link
Member

commented Mar 9, 2016

Instead of an alternate README, is there any enthusiasm for putting the build instructions in a BUILD.md and linking to it from the README.md file? We could keep minimal build instructions for the most popular platforms in the README (or not). Of course, the README would 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.

@jbergstroem

This comment has been minimized.

Copy link
Member Author

commented Mar 14, 2016

PR here: #5695

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.