You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Karthik Kambatla <ka...@cloudera.com> on 2015/12/21 05:59:49 UTC
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
Re: Highlighting communication on releases
Posted by Junping Du <jd...@hortonworks.com>.
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-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
Re: Highlighting communication on releases
Posted by Junping Du <jd...@hortonworks.com>.
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-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
Re: Highlighting communication on releases
Posted by Junping Du <jd...@hortonworks.com>.
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-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
Re: Highlighting communication on releases
Posted by Junping Du <jd...@hortonworks.com>.
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-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