I would like to re-iterate that committers please be very conservative now in merging patches into branch-2.1.
Spark is a very sophisticated (compiler, optimizer) project and sometimes one-line changes can have huge consequences and introduce regressions. If it is just a tiny optimization, don't merge it into branch-2.1. On Tue, Nov 22, 2016 at 9:37 AM, Sean Owen <so...@cloudera.com> wrote: > Thanks, this was another message that went to spam for me: > > http://apache-spark-developers-list.1001551.n3.nabble.com/ANNOUNCE-Apache- > Spark-branch-2-1-td19688.html > > Looks great -- cutting branch = in RC period. > > On Tue, Nov 22, 2016 at 5:31 PM Reynold Xin <r...@databricks.com> wrote: > >> I did send an email out with those information on Nov 1st. It is not >> meant to be in new feature development mode anymore. >> >> FWIW, I will cut an RC today to remind people of that. The RC will fail, >> but it can serve as a good reminder. >> >> On Tue, Nov 22, 2016 at 1:53 AM Sean Owen <so...@cloudera.com> wrote: >> >> Maybe I missed it, but did anyone declare a QA period? In the past I've >> not seen this, and just seen people start talking retrospectively about how >> "we're in QA now" until it stops. We have https://cwiki.apache.org/ >> confluence/display/SPARK/Wiki+Homepage saying it is already over, but >> clearly we're not doing RCs. >> >> We should make this more formal and predictable. We probably need a >> clearer definition of what changes in QA. I'm moving the wiki to >> spark.apache.org now and could try to put up some words around this when >> I move this page above today. >> >> On Mon, Nov 21, 2016 at 11:20 PM Joseph Bradley <jos...@databricks.com> >> wrote: >> >> To committers and contributors active in MLlib, >> >> Thanks everyone who has started helping with the QA tasks in >> SPARK-18316! I'd like to request that we stop committing non-critical >> changes to MLlib, including the Python and R APIs, since still-changing >> public APIs make it hard to QA. We need have already started to sign off >> on some QA tasks, but we may need to re-open them if changes are committed, >> especially if those changes are to public APIs. There's no need to push >> Python and R wrappers into 2.1 at the last minute. >> >> Let's focus on completing QA, after which we can resume committing API >> changes to master (not branch-2.1). >> >> Thanks everyone! >> Joseph >> >> >> -- >> >> Joseph Bradley >> >> Software Engineer - Machine Learning >> >> Databricks, Inc. >> >> [image: http://databricks.com] <http://databricks.com/> >> >>
