Re: submitting a hadoop patch doesn't trigger jenkins test run

[Yongjun Zhang <yz...@cloudera.com>]

Hi,

Thank you all for the input.

https://issues.apache.org/jira/browse/HADOOP-11320

was created for this issue. Welcome to give your further comments there.

Best,

--Yongjun

On Tue, Nov 25, 2014 at 10:26 PM, Colin McCabe <cm...@alumni.cmu.edu>
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 <yz...@cloudera.com>
> 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 <st...@hortonworks.com>
> > wrote:
> >
> > > On 25 November 2014 at 00:58, Bernd Eckenfels <ec...@zusammenkunft.net>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > Am Mon, 24 Nov 2014 16:16:00 -0800
> > > > schrieb Colin McCabe <cm...@alumni.cmu.edu>:
> > > >
> > > > > 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.
> > >
> > > --
> > > CONFIDENTIALITY NOTICE
> > > NOTICE: This message is intended for the use of the individual or
> entity
> > to
> > > which it is addressed and may contain information that is confidential,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notified
> > that
> > > any printing, copying, dissemination, distribution, disclosure or
> > > forwarding of this communication is strictly prohibited. If you have
> > > received this communication in error, please contact the sender
> > immediately
> > > and delete it from your system. Thank You.
> > >
> >
>