hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Junping Du <...@hortonworks.com>
Subject Re: Highlighting communication on releases
Date Mon, 21 Dec 2015 13:34:26 GMT
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 <kasha@cloudera.com>
Sent: Monday, December 21, 2015 4:59 AM
To: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
mapreduce-dev@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

Mime
View raw message