Was the duplication due to a script that generates the release note or is
this something that happened manually? If the former, it would be best for
that script to itself check for duplicates, I reckon. I’m not trying to
detail the original discussion but understand how we can prevent mistakes
>
> So what was in the 85MB file? I’m confused about the nature of the mistake
> that caused it.
>
There are very duplicate content. Every issue's release note repeated
hundreds of times. So it may be heplful to check this in precommit job.
Grep the issue number from release note and check whether
Busbey-MBA:hbase busbey$ git show cb0e9bb95599 | grep "Release Notes" | sort -u
# HBASE 2.2.0 Release Notes
Busbey-MBA:hbase busbey$ git show 61e9de9b82a9 | grep "Release Notes" | sort -u
# HBASE 2.2.0 Release Notes
Busbey-MBA:hbase busbey$ git checkout branch-2.2
Switched to branch 'branch-2.2'
So what was in the 85MB file? I’m confused about the nature of the mistake
that caused it.
On Tue, Jun 4, 2019 at 1:10 PM Sean Busbey wrote:
> changelog is a list of all the fixes. release notes is supposed to be
> the things we as a community think downstream users need to pay
> attention to.
changelog is a list of all the fixes. release notes is supposed to be
the things we as a community think downstream users need to pay
attention to.
The release notes in an archive should be related to the release in
question. Historically that has meant "all the maintenance releases in
this minor
I’m confused how an automatically generated file can vary so much in size.
Can the release notes file with an archive just target the release in
question and leave off the older stuff? What’s the difference in practice
between the release noted and changelog?
A pre-commit and possibly a presubmit
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
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
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 wrote:
> Currently putting them in the repo is how we get release notes into the
> source and binary artifacts we vote on.
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
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 wrote:
> Sorry. This large RELEASENOTES.md may be introduced by me. I committed a
> big RELEASENOTES.md to branch-2.2 yesterday.
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 于2019年6月4日周二 上午3:24写道：
> remote: warning: GH001: Large files detected. You may want to try Git Large
> File
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
13 matches
Mail list logo
