Thanks Karthik to bring up the topic. Comparing with small enhancement on email distribution for release/branch news, I think a more important thing is to make our community (contributor & committer) to be more aware on ongoing releases/branches.
I can see two improvements could be helpful here: - Beside email thread, we can have a central place (like wiki page: HowToContribute/HowToCommit) to keep updating the commit instructions/details for each releasing/unreleased branches by release manager. Following is a quick example: /*** prior to 2.6: closed to commit ... 2.6.4: commit to trunk, branch-2 and branch-2.6 2.7.2: commit to trunk, branch-2, branch-2.7 and branch-2.7.2 (assume RC hasn't been out which is not true today.) 2.8: commit to trunk, branch-2 and branch-2.8 2.9: commit to trunk and branch-2 ... ***/ Both contributor and committer can keep an eye on it. - Add a tools in post-commit to check if fix version is match with commits landing on related branches. If not, send notifications to patch contributor, committer (and may be release manager also) to correct it asap. Thoughts? Thanks, Junping ________________________________________ From: Karthik Kambatla <ka...@cloudera.com> Sent: Monday, December 21, 2015 4:59 AM To: common-...@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org Subject: Highlighting communication on releases Hi folks In the last few months, we have been shipping multiple releases - maintenance and minor - elevating the quality and purpose of our releases. With the increase in releases and related communication, I wonder if we need to highlight release-related communication in some way. Otherwise, it is easy to miss the details in the plethora of emails on dev lists. For instance, it appears committers might have missed the detail that branch-2.8 was cut. A couple of options I see: 1. Tag release-related emails with [RELEASE] or some other appropriate tag. 2. Separate mailing list for release specific information. May be, this list could be used for other project-level topics as well. common-dev@ has been overloaded for both common-specific and project-level discussions. Also, folks wouldn't have to email all -dev@lists. Would like to hear others' thoughts on the matter. Karthik
