+1
I would also be supportive of ripping it all out for the reasons that
Andrew already stated.
On 3/6/18 3:22 PM, Stack wrote:
Thanks lads. Let me look at purge of non-user javadocs and at building a
javadoc-only artifiact (then could purge all javadoc as per Andy).
S
On Tue, Mar 6, 2018 a
Thanks lads. Let me look at purge of non-user javadocs and at building a
javadoc-only artifiact (then could purge all javadoc as per Andy).
S
On Tue, Mar 6, 2018 at 11:45 AM, Sean Busbey wrote:
> if we keep any javadocs in the tarball they should just be the user
> facing javadocs (wether that
if we keep any javadocs in the tarball they should just be the user
facing javadocs (wether that includes testapidocs I could go either
way). I'd be in favor of dumping the javadocs entirely from the binary
tarball.
do we know why the apidocs are bigger than our binaries? are we
mistakingly includ
> I could make it so we do not build dev doc by default or that we do not
include it in our bin tarball?
The binary tarball is so huge at this point I think getting the size down
by pruning javadoc is reasonable, at least in the short term. We have
javadocs up on our site. They will also be availa
On the vote thread for hbase-2.0.0-beta-2, it was noted that the bulk of
our convenience bin tarball size is test javadoc [1] (~ > 50%). Should our
bin tarball include all possible doc both api and dev api for both test and
user?
I could make it so we do not build dev doc by default or that we do
