Sorry. I think I just replied to the wrong thread. :(
WQ On Thu, Sep 29, 2016 at 10:58 AM, Weiqing Yang <yangweiqing...@gmail.com> wrote: > +1 (non binding) > > > > RC4 is compiled and tested on the system: CentOS Linux release > 7.0.1406 / openjdk 1.8.0_102 / R 3.3.1 > > All tests passed. > > > > ./build/mvn -Pyarn -Phadoop-2.7 -Pkinesis-asl -Phive -Phive-thriftserver > -Dpyspark -Dsparkr -DskipTests clean package > > ./build/mvn -Pyarn -Phadoop-2.7 -Pkinesis-asl -Phive -Phive-thriftserver > -Dpyspark -Dsparkr test > > > > > > Best, > > Weiqing > > On Thu, Sep 29, 2016 at 8:02 AM, Cody Koeninger <c...@koeninger.org> > wrote: > >> Regarding documentation debt, is there a reason not to deploy >> documentation updates more frequently than releases? I recall this >> used to be the case. >> >> On Wed, Sep 28, 2016 at 3:35 PM, Joseph Bradley <jos...@databricks.com> >> wrote: >> > +1 for 4 months. With QA taking about a month, that's very reasonable. >> > >> > My main ask (especially for MLlib) is for contributors and committers to >> > take extra care not to delay on updating the Programming Guide for new >> APIs. >> > Documentation debt often collects and has to be paid off during QA, and >> a >> > longer cycle will exacerbate this problem. >> > >> > On Wed, Sep 28, 2016 at 7:30 AM, Tom Graves >> <tgraves...@yahoo.com.invalid> >> > wrote: >> >> >> >> +1 to 4 months. >> >> >> >> Tom >> >> >> >> >> >> On Tuesday, September 27, 2016 2:07 PM, Reynold Xin < >> r...@databricks.com> >> >> wrote: >> >> >> >> >> >> We are 2 months past releasing Spark 2.0.0, an important milestone for >> the >> >> project. Spark 2.0.0 deviated (took 6 month from the regular release >> cadence >> >> we had for the 1.x line, and we never explicitly discussed what the >> release >> >> cadence should look like for 2.x. Thus this email. >> >> >> >> During Spark 1.x, roughly every three months we make a new 1.x feature >> >> release (e.g. 1.5.0 comes out three months after 1.4.0). Development >> >> happened primarily in the first two months, and then a release branch >> was >> >> cut at the end of month 2, and the last month was reserved for QA and >> >> release preparation. >> >> >> >> During 2.0.0 development, I really enjoyed the longer release cycle >> >> because there was a lot of major changes happening and the longer time >> was >> >> critical for thinking through architectural changes as well as API >> design. >> >> While I don't expect the same degree of drastic changes in a 2.x >> feature >> >> release, I do think it'd make sense to increase the length of release >> cycle >> >> so we can make better designs. >> >> >> >> My strawman proposal is to maintain a regular release cadence, as we >> did >> >> in Spark 1.x, and increase the cycle from 3 months to 4 months. This >> >> effectively gives us ~50% more time to develop (in reality it'd be >> slightly >> >> less than 50% since longer dev time also means longer QA time). As for >> >> maintenance releases, I think those should still be cut on-demand, >> similar >> >> to Spark 1.x, but more aggressively. >> >> >> >> To put this into perspective, 4-month cycle means we will release Spark >> >> 2.1.0 at the end of Nov or early Dec (and branch cut / code freeze at >> the >> >> end of Oct). >> >> >> >> I am curious what others think. >> >> >> >> >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >> >> >
