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. >
