Yes, I had used "git merge --no-ff" while merging ATSv2 to trunk.
Maintaining history I believe can be useful as it can make reverts
easier if at all required.
And can be an easy reference point to look at who had contributed what
without having to go back to the branch.
Regards,
Varun Saxena.
O
Zhe Zhang created HDFS-12379:
Summary: NameNode getListing should use FileStatus instead of
HdfsFileStatus
Key: HDFS-12379
URL: https://issues.apache.org/jira/browse/HDFS-12379
Project: Hadoop HDFS
Xiao Chen created HDFS-12378:
Summary:
TestClientProtocolForPipelineRecovery#testZeroByteBlockRecovery fails on trunk
Key: HDFS-12378
URL: https://issues.apache.org/jira/browse/HDFS-12378
Project: Hadoop
Andrew Wang created HDFS-12377:
--
Summary: Refactor TestReadStripedFileWithDecoding to avoid test
timeouts
Key: HDFS-12377
URL: https://issues.apache.org/jira/browse/HDFS-12377
Project: Hadoop HDFS
Thanks Sangjin for the link to the previous discussions on this! I think
that helps answer Steve's questions.
As decided on that thread [1], YARN-5355 as a feature branch was merged to
trunk via "git merge --no-ff" .
Although trunk already had TSv2 code (alpha1) prior to this merge, we chose
to d
The "git" way of doing things would be to rebase the feature branch on
master (trunk) and then commit the patch stack.
Squashing the entire feature into a 10 MB megapatch is the "svn" way of
doing things.
The svn workflow evolved because merging feature branches back to trunk
was really painful i
I recall this discussion about a couple of years ago:
https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac2b3c76afd9eff1f78b177fabe9c4a96d9b3d0b@1440189889@%3Ccommon-dev.hadoop.apache.org%3E
On Wed, Aug 30, 2017 at 2:32 PM, Steve Loughran
wrote:
> I'd have assumed it would have gone in as one
I'd have assumed it would have gone in as one single patch, rather than a full
history. I don't see why the trunk needs all the evolutionary history of a
build.
What should our policy/process be here?
I do currently plan to merge the s3guard in as one single squashed patch; just
getting HADOOP
Hanisha Koneru created HDFS-12376:
-
Summary: Enable JournalNode Sync by default
Key: HDFS-12376
URL: https://issues.apache.org/jira/browse/HDFS-12376
Project: Hadoop HDFS
Issue Type: Task
[
https://issues.apache.org/jira/browse/HDFS-11294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Clampffer reopened HDFS-11294:
Reopening. Looks like this is a real issue that existing tests weren't
hitting. Given an HA c
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/508/
[Aug 29, 2017 11:21:14 AM] (sunilg) YARN-6386. Show decommissioning nodes in
new YARN UI. Contributed by
[Aug 29, 2017 11:36:22 AM] (aajisaka) HADOOP-14671. Upgrade to Apache Yetus
0.5.0.
[Aug 29, 2017 2:5
Thanks Brahma for comment on this thread. To be clear, I always update branch
version just before RC kicking off.
For 2.8.2 release, I don't have plan to involve big top or other third-party
test tools. As always, we will rely on test/verify efforts from community
especially from large deployed
Wenxin He created HDFS-12375:
Summary: Fail to start/stop journalnodes using
start-dfs.sh/stop-dfs.sh.
Key: HDFS-12375
URL: https://issues.apache.org/jira/browse/HDFS-12375
Project: Hadoop HDFS
13 matches
Mail list logo
