The various release notes and changes.txt come up frequently in a listing of large-ish objects committed in the repo, along with autogenerated protobuf and thrift files. It's fine if we tolerate them all in return for something. Not requiring local IDL compilers to build is a reasonable tradeoff for checking in what can be (and is) generated. I'm less convinced about release notes, given they can be made readily available online, and already come in an online form on JIRA with no work required from us beyond proper attention to fix versions, but I don't have a strong opinion about it.
On Tue, Jun 4, 2019 at 10:35 AM Sean Busbey <[email protected]> wrote: > presuming you mean the two files from your original email: > > cb0e9bb95599 86MiB RELEASENOTES.md > 61e9de9b82a9 14MiB RELEASENOTES.md > > these are both for HBase 2.2.0. Since branch-2.2 currently shows: > > > Busbey-MBA:hbase busbey$ git checkout branch-2.2 > Already on 'branch-2.2' > Your branch is up to date with 'origin/branch-2.2'. > Busbey-MBA:hbase busbey$ ls -lah *.md > -rw-r--r-- 1 busbey staff 100K Jun 4 12:24 CHANGES.md > -rw-r--r-- 1 busbey staff 69K Jun 4 12:24 RELEASENOTES.md > > Yes, I'd wager it was also a mistake. > > If we don't want files over some threshold size, we should do what we > normally do when we want to change committer behavior: offer people > tools that help them do the right thing without thinking about it too > much. In this case I would guess a client side git pre-commit hook > that stopped things when files are too big, e.g. 10MiB. When a case > comes up that there's something bigger we need to commit then folks > can use their judgement and discuss it on dev@ if they think it's > contentious. > > On Tue, Jun 4, 2019 at 12:18 PM Andrew Purtell <[email protected]> > wrote: > > > > There's an 80 MB release notes file, possibly a mistake; the next largest > > object is an 11 MB release notes file. Also a mistake? > > > > On Tue, Jun 4, 2019 at 10:11 AM Sean Busbey <[email protected]> wrote: > > > > > Currently putting them in the repo is how we get release notes into the > > > source and binary artifacts we vote on. It's really convenient for > making > > > sure folks who download things have some version of the notes. > > > > > > We've been including the bare file in the dist area as well, so we'd > face > > > the same issue around distributing a large file (probably more likely > to > > > face it since it's compressed in the tarballs). > > > > > > I agree we should have an up to date rendered version on the website > (it's > > > been an outstanding doc jira). But the files usually aren't very large > and > > > having them shipped in the release is nice. > > > > > > On Tue, Jun 4, 2019, 12:04 Andrew Purtell <[email protected]> wrote: > > > > > > > What do you think about linking to a remote site-based release notes > file > > > > instead of checking them into the main repo? > > > > > > > > On Mon, Jun 3, 2019 at 10:12 PM Guanghao Zhang <[email protected]> > > > wrote: > > > > > > > > > Sorry. This large RELEASENOTES.md may be introduced by me. I > committed > > > a > > > > > big RELEASENOTES.md to branch-2.2 yesterday. I fixed it today. And > > > roll a > > > > > new 2.2.0RC5. Thanks. > > > > > > > > > > Andrew Purtell <[email protected]> 于2019年6月4日周二 上午3:24写道： > > > > > > > > > > > remote: warning: GH001: Large files detected. You may want to > try Git > > > > > Large > > > > > > File Storage - https://git-lfs.github.com. > > > > > > remote: warning: See http://git.io/iEPt8g for more information. > > > > > > remote: warning: File RELEASENOTES.md is 85.80 MB; this is larger > > > than > > > > > > GitHub's recommended maximum file size of 50.00 MB > > > > > > > > > > > > The object is cb0e9bb95599 86MiB RELEASENOTES.md > > > > > > > > > > > > Incidentially, the next largest file is also a markup release > notes > > > > file. > > > > > > > > > > > > 61e9de9b82a9 14MiB RELEASENOTES.md > > > > > > > > > > > > As far as I can tell cb0e9bb95599 is not referenced from > anywhere. So > > > > > > eventually garbage collection both on the github side and in > local > > > > > > repositories will clear it out? > > > > > > > > > > > > This leads to the natural question of whether we should be > checking > > > in > > > > > such > > > > > > really large autogenerated files. There are release policy > > > > implications. > > > > > > Perhaps we can check in very small release notes files containing > > > only > > > > a > > > > > > URL to an online resource? Put the release notes objects in > > > hbase-site > > > > ? > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Andrew > > > > > > > > > > > > Words like orphans lost among the crosstalk, meaning torn from > > > truth's > > > > > > decrepit hands > > > > > > - A23, Crosstalk > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Andrew > > > > > > > > Words like orphans lost among the crosstalk, meaning torn from > truth's > > > > decrepit hands > > > > - A23, Crosstalk > > > > > > > > > > > > > -- > > Best regards, > > Andrew > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > decrepit hands > > - A23, Crosstalk > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
