[
https://issues.apache.org/jira/browse/HDFS-12615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478432#comment-16478432
]
Chris Douglas commented on HDFS-12615:
--------------------------------------
bq. Any Jira which has not been released, we should certainly revert.
A blanket veto over a clerical error is not on the table. A set of unrelated
features and fixes were unhelpfully linked from a single JIRA. Let's clean it
up and move significant features- like security- to design doc + branch,
leaving bug fixes and the like to normal dev on trunk, as we would with any
other module. Particularly for code that only affects RBF, isolating it on a
branch doesn't do anything for the stability of trunk.
bq. I don't quite agree with the patch count logic, for I have seen patches
with are more than 200 KB at times. Let us just say "we know a big feature when
we see it"
I was referring to the 5/9 patches implementing these features. Legalese
defining when a branch is required is not a good use of anyone's time. Let's
not belabor it. However, you requested _all_ development move to a branch,
based on an impression that you explicitly have not verified. Without seeking
objective criteria that apply to all situations, you need to research this
particular patchset to ground your claims about _it_.
Let's be concrete. You have the impression that (a) changes committed to trunk
affect non-RBF deployments and (b) RBF features miss critical cases. Those are
demonstrable.
bq. I *feel* that a JIRA that has these following features [...] *Sounds like*
a major undertaking in my mind and *feels like* these do need a branch and
these are significant features.
RBF has a significant _roadmap_. A flat list of tasks- with mixed granularity-
is a poor way to organize it.
bq. [...] since they are not very keen on communicating details, I am proposing
that you move all this work to a branch and bring it back when the whole idea
is baked
Not everyone participating in RBF development has worked in OSS projects,
before. It's fine to explore ideas in code, collaboratively, in JIRA. Failing
to signal which JIRAs are variations on a theme (e.g., protobuf boilerplate),
prototypes, or features affecting non-RBF: that's not OK. Reviewers can't
follow every JIRA, they need help finding the relevant signal.
Your confidence that people working on RBF are applying reasonable filters and
*soliciting* others' opinion is extremely important. From a random sampling,
that seems to be happening. Reviewing the code in issues [~arpitagarwal]
cited... they may "look non-trivial at a glance", but after a slightly longer
glance, they look pretty straightforward to me. Or at least, they follow from
the design of the router.
bq. Perhaps there is a communication problem here. I am not sure where your
assumption comes from; reading the comments on the security patch, I am not
able to come to that conclusion. Please take a look at HDFS-12284. [...] If we
both are reading the same comments, I am at a loss on how you came to the
conclusion that it was a proposal and not a patch.
Committing a patch that claims to add security, without asking for broader
review, would be absurd. Reading a discussion about a lack of clarity on
_delegation tokens_ and concluding that group believes its implementation is
ready to merge... that requires more assumptions about those developers' intent
and competence than to conclude "prototype". _However_ if it were being
developed in a branch, that signal would be unambiguous.
bq. It will benefit the RBF feature as well as future maintainers to have a
design notes or a detailed change description beyond a 1-line summary because
most are large patches
>From the samples I read, this is a recurring problem. Many RBF JIRAs should
>have more prose around the design tradeoffs, not just comments on the code.
>Taking HDFS-13224 as an example, one would need to read the patch to
>understand what was implemented, and how. Again, most of these follow from the
>RBF design and the larger patch size often comes from PB boilerplate, but
>raising the salient details both for review and for future maintainers (I'm
>glad you brought this up) is not optional.
> Router-based HDFS federation phase 2
> ------------------------------------
>
> Key: HDFS-12615
> URL: https://issues.apache.org/jira/browse/HDFS-12615
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Íñigo Goiri
> Assignee: Íñigo Goiri
> Priority: Major
> Labels: RBF
>
> This umbrella JIRA tracks set of improvements over the Router-based HDFS
> federation (HDFS-10467).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
