[
https://issues.apache.org/jira/browse/HADOOP-11320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231847#comment-14231847
]
Yongjun Zhang commented on HADOOP-11320:
----------------------------------------
Based on the email discussion, it seems beneficial to allow the option of
making changes that span sub-projects. Still, reviewer can decide whether the
change need to be broken down to sub-patches. So we won't really lose much by
having this option.
Thanks [~cnauroth], [[email protected]], [~cmccabe], [~vinayrpet],
[~b.eckenfels] for the feedback.
I'm re-opening this jira for increasing the timeout. It would be nice to make
the timeout adaptable to the patch, say, if a patch only spans a single
sub-project, keep the original timeout, otherwise, adjust it accordingly.
{code}
On Tue, Nov 25, 2014 at 10:26 PM, Colin McCabe <[email protected]> wrote:
+1 for increasing the test timeout for tests spanning multiple sub-projects.
I can see the value in what Steve L. suggested... if you make a major
change that touches a particular subproject, you should try to get the
approval of a committer who knows that subproject. But I don't think that
forcing artificial patch splits is the way to do this... There are also
some patches that are completely mechanical and don't really require the
involvement of YARN / HDFS committer, even if they change that project.
For example, fixing a misspelling in the name of a hadoop-common API.
Colin
On Tue, Nov 25, 2014 at 8:45 AM, Yongjun Zhang <[email protected]> wrote:
> Thanks all for the feedback. To summarize (and I have a suggestion at the
> end of this email), there are two scenarios:
>
> 1. A change that span multiple *bigger* projects. r.g. hadoop, hbase.
> 2. A change that span multiple *sub* projects* within hadoop, e.g.,
> common, hdfs, yarn
>
> For 1, it's required for the change to be backward compatible, thus
> splitting change for multiple *bigger* projects is a must.
>
> For 2, there are two sub types,
>
> - 2.1 those changes that can be made within hadoop sub-projects, and
> there is no external impact
> - 2.2 those changes that have external impact, that is, the changes
> involve adding new APIs and marking old API deprecated, and
> corresponding
> changes in other *bigger* projects will have to be made independently.
> *But
> the changes within hadoop subjects can still be done altogether.*
>
> I think (Please correct me if I'm wrong):
>
> - What Colin referred to is 2.1 and changes within hadoop sub-subjects
> for 2.2;
> - Steve's "not for changes across hadoop-common and hdfs, or
> hadoop-common and yarn" means 2.1, Steve's "changes that only
> span hdfs-and-yarn would be fairly doubtful too." implies his doubt of
> existence of 2.1.
>
> For changes of 2.1 (if any) and *hadoop* changes of 2.2, we do have an
> option of making the change across all hadoop sub-projects altogether, to
> save the multiple steps Colin referred to.
>
> If this option is feasible, should we consider increasing the jenkins
> timeout for this kind of changes (I mean making the timeout adjustable, if
> it's for single sub-project, use the old timeout; otherwise, increase
> accordingly) so that we have at least this option when needed?
>
> Thanks.
>
> --Yongjun
>
>
> On Tue, Nov 25, 2014 at 2:28 AM, Steve Loughran <[email protected]>
> wrote:
>
> > On 25 November 2014 at 00:58, Bernd Eckenfels <[email protected]>
> > wrote:
> >
> > > Hello,
> > >
> > > Am Mon, 24 Nov 2014 16:16:00 -0800
> > > schrieb Colin McCabe <[email protected]>:
> > >
> > > > Conceptually, I think it's important to support patches that modify
> > > > multiple sub-projects. Otherwise refactoring things in common
> > > > becomes a multi-step process.
> > >
> > > This might be rather philosophical (and I dont want to argue the need
> > > to have the patch infrastructure work for the multi-project case),
> > > howevere if a multi-project change cannot be applied in multiple steps
> > > it is probably also not safe at runtime (unless the multiple projects
> > > belong to a single instance/artifact). And then beeing forced to
> > > commit/compile/test in multiple steps actually increases the
> > > dependencies topology.
> > >
> >
> > +1 for changes that span, say hadoop and hbase. but not for changes
> across
> > hadoop-common and hdfs, or hadoop-common and yarn. changes that only span
> > hdfs-and-yarn would be fairly doubtful too.
> >
> > there is a dependency graph in hadoop's own jars —and cross module (not
> > cross project) changes do need to happen.
> >
{code}
> Submitting a hadoop patch doesn't trigger jenkins test run
> ----------------------------------------------------------
>
> Key: HADOOP-11320
> URL: https://issues.apache.org/jira/browse/HADOOP-11320
> Project: Hadoop Common
> Issue Type: Bug
> Components: build
> Reporter: Yongjun Zhang
> Attachments: HADOOP-11293.003.patch
>
>
> See details in INFRA-8655.
> Per [~abayer] and [~cnauroth]'s feedback there , I'm creating this jira to
> investigate the possible bug in dev-support/test-patch.sh script.
> Thanks Andrew and Chris.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
