> On 6 May 2015, at 17:50, Vinod Kumar Vavilapalli <[email protected]> > wrote: > > +1 for the idea in general. > > We definitely need design discussion and consensus upfront, lest branches > turn into dumping grounds and people complaining about why their branches > (instead of patches) do not get merged. > > As others noted, for the same reason above, active supervision of branches is > desired. > > Echoing Bikas and Zhijie's comments, if two branches are completely > orthogonal (may be because it is all new features/code), the order doesn't > matter. But if two proposals potentially have a large conflict of code-base > or functionality, we should discuss and arrive at a branch-order upfront so > as to avoid thrash. > > IAC, I'd definitely like us to avoid "why is this not being done in a branch" > conflicts. More often than not, it ends up being a subjective decision. We > can actively try to push big enough features into their branches, but we > should be open to cases where that may not make all the sense. > > Thanks > +Vinod
one more thing: anyone who branches needs to set up a jenkins build for that, emails sent to them & not the core mailing lists
