Sorry my bad, I named Andrew Wang for Andrew Bayer in my last mail, both of
them helped anyways:-) So thanks to all for the help on this matter!

--Yongjun

On Thu, Dec 11, 2014 at 3:38 PM, Yongjun Zhang <yzh...@cloudera.com> wrote:

> Many thanks to Ted Yu, Steve Loughran and Andrew Wang for replying in the
> jira and Steve/Andrew for making the related changes!
>
> --Yongjun
>
> On Thu, Dec 11, 2014 at 12:41 PM, Yongjun Zhang <yzh...@cloudera.com>
> wrote:
>
>> Hi,
>>
>> I wonder if anyone can help on resolving HADOOP-11320
>> <https://issues.apache.org/jira/browse/HADOOP-11320> to increase timeout
>> for jenkins test of crossing-subproject patches?
>>
>> Thanks a lot,
>>
>> --Yongjun
>>
>> On Tue, Dec 2, 2014 at 10:10 AM, Yongjun Zhang <yzh...@cloudera.com>
>> wrote:
>>
>>> 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 <cmcc...@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 <yzh...@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 <
>>>> ste...@hortonworks.com>
>>>> > wrote:
>>>> >
>>>> > > On 25 November 2014 at 00:58, Bernd Eckenfels <
>>>> e...@zusammenkunft.net>
>>>> > > wrote:
>>>> > >
>>>> > > > Hello,
>>>> > > >
>>>> > > > Am Mon, 24 Nov 2014 16:16:00 -0800
>>>> > > > schrieb Colin McCabe <cmcc...@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.
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>

Reply via email to