Re: Where to put some code examples?
Also if they are general Hadoop big data examples were happy to carry them in bigtop as well ... Especially if they touch multiple areas of the Hadoop ecosystem > On Jun 23, 2015, at 11:56 PM, Andrew Wang wrote: > > Yea, throw them under dev-support. It'd be good to link them up on the wiki > or website too so they're more findable. > > Related, we could also use a README in dev-support as an overview of what > everything does. > >> On Tue, Jun 23, 2015 at 8:19 PM, Sean Busbey wrote: >> >> Could they go under dev-support? >> >>> On Tue, Jun 23, 2015 at 4:29 PM, Ray Chiang wrote: >>> >>> So, as far as I can see, Hadoop has the main developer area for core >> Hadoop >>> code, unit tests in the test directories, user scripts (like >>> hadoop/mapred/yarn), and build scripts. >>> >>> I've got some utilities that are really for Hadoop contributors. These >>> serve two purposes: >>> >>> 1. These are just generally useful as private API examples >>> 2. They have some utility for developer purposes (e.g. the random >> .jhist >>> generator I'm working on for MAPREDUCE-6376) >>> >>> Does anyone have suggestions for where such code bits (and possibly >>> corresponding scripts) should go? >>> >>> -Ray >> >> >> >> -- >> Sean >>
Re: Where to put some code examples?
Yea, throw them under dev-support. It'd be good to link them up on the wiki or website too so they're more findable. Related, we could also use a README in dev-support as an overview of what everything does. On Tue, Jun 23, 2015 at 8:19 PM, Sean Busbey wrote: > Could they go under dev-support? > > On Tue, Jun 23, 2015 at 4:29 PM, Ray Chiang wrote: > > > So, as far as I can see, Hadoop has the main developer area for core > Hadoop > > code, unit tests in the test directories, user scripts (like > > hadoop/mapred/yarn), and build scripts. > > > > I've got some utilities that are really for Hadoop contributors. These > > serve two purposes: > > > >1. These are just generally useful as private API examples > >2. They have some utility for developer purposes (e.g. the random > .jhist > >generator I'm working on for MAPREDUCE-6376) > > > > Does anyone have suggestions for where such code bits (and possibly > > corresponding scripts) should go? > > > > -Ray > > > > > > -- > Sean >
Re: Pre-integration tests failing
On 24/06/2015 04:22, Sean Busbey wrote: Probably not (barring maven attempting to grab SNAPSHOT versions of other modules while building). What are the machine specs like? the complete unit test set requires a fair bit of machine power (i.e. more than my laptop can handle). The Linux machine is pretty old, it's a 4-core Opteron with 8Gb mem. I haven't attempted test runs on Solaris yet as I know they won't complete successfully. -- Alan Burlison --
Re: [DISCUSS] More Maintenance Releases
On Tue, Jun 23, 2015 at 12:30 PM, Andrew Wang wrote: > There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and > enough PMCs who will vote on releases, there's no reason we can't maintain > both. > > However, based on the discussion at Hadoop Summit with Yahoo and Twitter, > their interest is primarily in 2.6, and Daryn mentioned the need to get 2.6 > stable before they can move to 2.7. So, if we want to help out these big > users, it seems like we should focus on maintaining 2.6. > > Allen also brought up the issue of JDK6. I see a few options (ranked best > to worst in my eyes): > > * Add multi-JDK support to test-patch > * Keep using JDK7 for precommit, and keep an eye on a nightly JDK6 run > * Drop support for JDK6 in 2.6.x, since no one is using it anymore > > #3 is the most easiest and probably fine for 95% of users, but doing a big > compat break is not how I'd want to kick off a stable release line. #2 > isn't too bad if we don't want to wait for #1. > > I believe work on adding multi jdk is on-going for patch test. Should be high on the list once we get our dev branch up. -- Sean
Re: Pre-integration tests failing
Probably not (barring maven attempting to grab SNAPSHOT versions of other modules while building). What are the machine specs like? the complete unit test set requires a fair bit of machine power (i.e. more than my laptop can handle). On Tue, Jun 23, 2015 at 3:58 PM, Alan Burlison wrote: > On 23/06/2015 21:42, Allen Wittenauer wrote: > > I'm trying to test stuff prior to submission, following the instructions >>> at http://wiki.apache.org/hadoop/HowToContribute and even when using an >>> unmodified git clone from the repo on a LLinux machine I've failed to get a >>> clean test run. Normally I end up with a timeout error somewhere in >>> hadoop-common, but it's taking an hour before it fails. Is that normal? >>> >> >> I think parts of the ASF infra is sick. I’ve been having problems too. >> > > I'm running the tests locally, is the ASF infrastructure sill involved? > > -- > Alan Burlison > -- > -- Sean
Re: Where to put some code examples?
Could they go under dev-support? On Tue, Jun 23, 2015 at 4:29 PM, Ray Chiang wrote: > So, as far as I can see, Hadoop has the main developer area for core Hadoop > code, unit tests in the test directories, user scripts (like > hadoop/mapred/yarn), and build scripts. > > I've got some utilities that are really for Hadoop contributors. These > serve two purposes: > >1. These are just generally useful as private API examples >2. They have some utility for developer purposes (e.g. the random .jhist >generator I'm working on for MAPREDUCE-6376) > > Does anyone have suggestions for where such code bits (and possibly > corresponding scripts) should go? > > -Ray > -- Sean
Where to put some code examples?
So, as far as I can see, Hadoop has the main developer area for core Hadoop code, unit tests in the test directories, user scripts (like hadoop/mapred/yarn), and build scripts. I've got some utilities that are really for Hadoop contributors. These serve two purposes: 1. These are just generally useful as private API examples 2. They have some utility for developer purposes (e.g. the random .jhist generator I'm working on for MAPREDUCE-6376) Does anyone have suggestions for where such code bits (and possibly corresponding scripts) should go? -Ray
Re: Pre-integration tests failing
On 23/06/2015 21:42, Allen Wittenauer wrote: I'm trying to test stuff prior to submission, following the instructions at http://wiki.apache.org/hadoop/HowToContribute and even when using an unmodified git clone from the repo on a LLinux machine I've failed to get a clean test run. Normally I end up with a timeout error somewhere in hadoop-common, but it's taking an hour before it fails. Is that normal? I think parts of the ASF infra is sick. I’ve been having problems too. I'm running the tests locally, is the ASF infrastructure sill involved? -- Alan Burlison --
Re: Pre-integration tests failing
On Jun 23, 2015, at 1:32 PM, Alan Burlison wrote: > I'm trying to test stuff prior to submission, following the instructions at > http://wiki.apache.org/hadoop/HowToContribute and even when using an > unmodified git clone from the repo on a LLinux machine I've failed to get a > clean test run. Normally I end up with a timeout error somewhere in > hadoop-common, but it's taking an hour before it fails. Is that normal? I think parts of the ASF infra is sick. I’ve been having problems too.
Pre-integration tests failing
I'm trying to test stuff prior to submission, following the instructions at http://wiki.apache.org/hadoop/HowToContribute and even when using an unmodified git clone from the repo on a LLinux machine I've failed to get a clean test run. Normally I end up with a timeout error somewhere in hadoop-common, but it's taking an hour before it fails. Is that normal? -- Alan Burlison --
Re: [DISCUSS] More Maintenance Releases
On Tue, Jun 23, 2015 at 10:30 AM, Andrew Wang wrote: > There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and > enough PMCs who will vote on releases, there's no reason we can't maintain > both. > > However, based on the discussion at Hadoop Summit with Yahoo and Twitter, > their interest is primarily in 2.6, and Daryn mentioned the need to get 2.6 > stable before they can move to 2.7. So, if we want to help out these big > users, it seems like we should focus on maintaining 2.6. > It would be nice to hear from the big users on the topic. They are already on 2.6 and some of them have already done a bunch of backports. Given it will take us a month or two (based on past experience) to get the first release out, it is not clear to me if we should start focusing on 2.6 or 2.7. But again, as you say, if there are people willing to RM these releases, I see value in improving both lines. > > Allen also brought up the issue of JDK6. I see a few options (ranked best > to worst in my eyes): > > * Add multi-JDK support to test-patch > * Keep using JDK7 for precommit, and keep an eye on a nightly JDK6 run > * Drop support for JDK6 in 2.6.x, since no one is using it anymore > > #3 is the most easiest and probably fine for 95% of users, but doing a big > compat break is not how I'd want to kick off a stable release line. #2 > isn't too bad if we don't want to wait for #1. > > Finally, an issue that Karthik mentioned at Hadoop Summit is that > CHANGES.txt maintenance becomes a huge burden when doing backports after > the initial commit. e.g. if I was backporting something to branch-2.6, I'd > potentially need to update CHANGES.txt in trunk, branch-2, branch-2.7 to > move the JIRA # to the right version. If we either automated or dropped > CHANGES.txt, the process would be much smoother. > +1 for ditching CHANGES.txt. I reached out to Allen recently. He wanted to clean up his scripts more before dropping CHANGES.txt altogether. Should we target 2.8 for this? > > Best, > Andrew > > On Tue, Jun 23, 2015 at 6:05 AM, Akira AJISAKA > > wrote: > > > Thanks Tsuyoshi for the comment. > > > > Targeting to 2.7 looks good to me, however, I'd like to maintenance > > branch-2.6 also. It's only about a half year since 2.6.0 was released. > > I don't want to abandon relatively new branches. > > > > > > On 6/23/15 16:05, Tsuyoshi Ozawa wrote: > > > >> Thank you for clarification, Karthik. > >> > >> I'd also like to work on stable release management with community. > >> > >> I'm thinking of speedy release against branch for > >> making community feedback faster (e.g. current next version is 2.8, so > >> cherry-picking to 2.7 and releasing it are useful work for users). > >> > >> I know that code base of 2.7.1 is now freezing currently, I'd love to > >> work from 2.7.2 release if possible. > >> > >> Cheers, > >> - Tsuyoshi > >> > >> On Tue, Jun 23, 2015 at 5:02 AM, Colin P. McCabe > >> wrote: > >> > >>> +1 for creating a maintenance release with a more rapid release > >>> cadence and more effort put into stability backports. I think this > >>> would really be great for the project. > >>> > >>> Colin > >>> > >>> On Mon, Jun 22, 2015 at 2:43 AM, Akira AJISAKA > >>> wrote: > >>> > Hi everyone, > > In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that > Apache > Hadoop developers at Yahoo!, Twitter, and other non-distributors work > very > hard to maintenance Hadoop by cherry-picking patches to their own > branches. > > I want to share the work with the community. If we can cherry-pick bug > fix > patches and have more maintenance releases, it'd be very happy not > only > for > users but also for developers who work very hard for stabilizing their > own > branches. > > To have more maintenance releases, I propose two changes: > > * Major/Minor/Trivial bug fixes can be cherry-picked > * (Roughly) Monthly maintenance release > > I would like to start the work from branch-2.6. If the change will be > accepted by the community, I'm willing to work for the maintenance, > as a > release manager. > > Best regards, > Akira > > >>> > > > -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es
Re: [DISCUSS] More Maintenance Releases
There's no reason we have to choose 2.6 xor 2.7. If we have willing RMs and enough PMCs who will vote on releases, there's no reason we can't maintain both. However, based on the discussion at Hadoop Summit with Yahoo and Twitter, their interest is primarily in 2.6, and Daryn mentioned the need to get 2.6 stable before they can move to 2.7. So, if we want to help out these big users, it seems like we should focus on maintaining 2.6. Allen also brought up the issue of JDK6. I see a few options (ranked best to worst in my eyes): * Add multi-JDK support to test-patch * Keep using JDK7 for precommit, and keep an eye on a nightly JDK6 run * Drop support for JDK6 in 2.6.x, since no one is using it anymore #3 is the most easiest and probably fine for 95% of users, but doing a big compat break is not how I'd want to kick off a stable release line. #2 isn't too bad if we don't want to wait for #1. Finally, an issue that Karthik mentioned at Hadoop Summit is that CHANGES.txt maintenance becomes a huge burden when doing backports after the initial commit. e.g. if I was backporting something to branch-2.6, I'd potentially need to update CHANGES.txt in trunk, branch-2, branch-2.7 to move the JIRA # to the right version. If we either automated or dropped CHANGES.txt, the process would be much smoother. Best, Andrew On Tue, Jun 23, 2015 at 6:05 AM, Akira AJISAKA wrote: > Thanks Tsuyoshi for the comment. > > Targeting to 2.7 looks good to me, however, I'd like to maintenance > branch-2.6 also. It's only about a half year since 2.6.0 was released. > I don't want to abandon relatively new branches. > > > On 6/23/15 16:05, Tsuyoshi Ozawa wrote: > >> Thank you for clarification, Karthik. >> >> I'd also like to work on stable release management with community. >> >> I'm thinking of speedy release against branch for >> making community feedback faster (e.g. current next version is 2.8, so >> cherry-picking to 2.7 and releasing it are useful work for users). >> >> I know that code base of 2.7.1 is now freezing currently, I'd love to >> work from 2.7.2 release if possible. >> >> Cheers, >> - Tsuyoshi >> >> On Tue, Jun 23, 2015 at 5:02 AM, Colin P. McCabe >> wrote: >> >>> +1 for creating a maintenance release with a more rapid release >>> cadence and more effort put into stability backports. I think this >>> would really be great for the project. >>> >>> Colin >>> >>> On Mon, Jun 22, 2015 at 2:43 AM, Akira AJISAKA >>> wrote: >>> Hi everyone, In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that Apache Hadoop developers at Yahoo!, Twitter, and other non-distributors work very hard to maintenance Hadoop by cherry-picking patches to their own branches. I want to share the work with the community. If we can cherry-pick bug fix patches and have more maintenance releases, it'd be very happy not only for users but also for developers who work very hard for stabilizing their own branches. To have more maintenance releases, I propose two changes: * Major/Minor/Trivial bug fixes can be cherry-picked * (Roughly) Monthly maintenance release I would like to start the work from branch-2.6. If the change will be accepted by the community, I'm willing to work for the maintenance, as a release manager. Best regards, Akira >>> >
[jira] [Created] (HADOOP-12114) Make hadoop-tools/hadoop-pipes Native code -Wall-clean
Alan Burlison created HADOOP-12114: -- Summary: Make hadoop-tools/hadoop-pipes Native code -Wall-clean Key: HADOOP-12114 URL: https://issues.apache.org/jira/browse/HADOOP-12114 Project: Hadoop Common Issue Type: Sub-task Components: native Affects Versions: 2.7.0 Reporter: Alan Burlison Assignee: Alan Burlison As we specify -Wall as a default compilation flag, it would be helpful if the Native code was -Wall-clean -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HADOOP-12113) update test-patch branch to latest code
Allen Wittenauer created HADOOP-12113: - Summary: update test-patch branch to latest code Key: HADOOP-12113 URL: https://issues.apache.org/jira/browse/HADOOP-12113 Project: Hadoop Common Issue Type: Sub-task Reporter: Allen Wittenauer [~sekikn] and I have been working on github. We should update the codebase to reflect all of those changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HADOOP-12112) Make hadoop-common-project Native code -Wall-clean
Alan Burlison created HADOOP-12112: -- Summary: Make hadoop-common-project Native code -Wall-clean Key: HADOOP-12112 URL: https://issues.apache.org/jira/browse/HADOOP-12112 Project: Hadoop Common Issue Type: Sub-task Components: native Affects Versions: 2.7.0 Reporter: Alan Burlison Assignee: Alan Burlison As we specify -Wall as a default compilation flag, it would be helpful if the Native code was -Wall-clean -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] More Maintenance Releases
Thanks Tsuyoshi for the comment. Targeting to 2.7 looks good to me, however, I'd like to maintenance branch-2.6 also. It's only about a half year since 2.6.0 was released. I don't want to abandon relatively new branches. On 6/23/15 16:05, Tsuyoshi Ozawa wrote: Thank you for clarification, Karthik. I'd also like to work on stable release management with community. I'm thinking of speedy release against branch for making community feedback faster (e.g. current next version is 2.8, so cherry-picking to 2.7 and releasing it are useful work for users). I know that code base of 2.7.1 is now freezing currently, I'd love to work from 2.7.2 release if possible. Cheers, - Tsuyoshi On Tue, Jun 23, 2015 at 5:02 AM, Colin P. McCabe wrote: +1 for creating a maintenance release with a more rapid release cadence and more effort put into stability backports. I think this would really be great for the project. Colin On Mon, Jun 22, 2015 at 2:43 AM, Akira AJISAKA wrote: Hi everyone, In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that Apache Hadoop developers at Yahoo!, Twitter, and other non-distributors work very hard to maintenance Hadoop by cherry-picking patches to their own branches. I want to share the work with the community. If we can cherry-pick bug fix patches and have more maintenance releases, it'd be very happy not only for users but also for developers who work very hard for stabilizing their own branches. To have more maintenance releases, I propose two changes: * Major/Minor/Trivial bug fixes can be cherry-picked * (Roughly) Monthly maintenance release I would like to start the work from branch-2.6. If the change will be accepted by the community, I'm willing to work for the maintenance, as a release manager. Best regards, Akira
Re: [DISCUSS] More Maintenance Releases
Thanks Allen for reminding me of supporting JDK6. If 2.6 is the target, any commmiter needs to check a bug fix patch when cherry-picking it. For trunk, I'm thinking we need to decide what we should do for release 3.x, in another thread. I'm okay to discuss it again. On 6/23/15 01:19, Allen Wittenauer wrote: If 2.6 is the target, someone will have to verify that any cherry-picked patches actually work with JDK6 since the PMC voted to officially kill backward compatibility in a minor release. It’s going to be easier and probably smarter to fix 2.7 if that’s really desired. [1] Frankly, I’d rather see effort spent on stabilizing trunk and ditching the now broken branch-2. We’re approaching the 4 year anniversary of 0.23.0’s release (which later begat 2.x, which is already past the 3 year mark). It’s hard to claim health when its been so long since a branch off of trunk was cut and turned into something official. [1] Kengo and I are hard at work getting multiJDK testing working in Yetus, but it’s not quite ready for prime time. :( It could certain help here, but… it’s not very stable yet. On Jun 22, 2015, at 7:50 AM, Karthik Kambatla wrote: Thanks for starting this thread, Akira. +1 to more maintenance releases. More stable upstream releases avoids duplicating cherry-pick work across consumers/vendors, and shows the maturity of the project to users. I see value in backporting blocker/critical issues, but have mixed feelings about doing the same for major/minor/trivial issues. IMO, every commit has non-zero potential to introduce other bugs. Depending on the kind of fix (say, documentation), it might be okay to include these non-critical fixes. One approach could be to allow all bug fixes for 2.x.1, blocker/critical for 2.x.2, blocker for 2.x.3 (or something along those lines) to ensure increasing stability of maintenance releases? I am also +1 to any committer picking up RM duties for a maintenance release. It is healthy to have more people participate in the release process, so long as we have some method to maintenance release madness. A committer (who is not yet a PMC member) could be a Release Manager, but his vote is not binding for the release. I RM-ed the 2.5.x releases as a committer. RM-ing a release and voting non-binding could be a good way to remind the PMC to include the committer in PMC :) Cheers Karthik On Mon, Jun 22, 2015 at 4:36 AM, Tsuyoshi Ozawa wrote: Hi Akira, Thank you for starting interesting topic. +1 on the idea of More Maintenance Releases for old branches. It would be good if this activity is more coupled with Apache Yetus for users. BTW, I don't know one of committers, who is not PMC, can be a release manager. Does anyone know about this? It's described in detail as follows: http://hadoop.apache.org/bylaws#Decision+Making Release Manager A Release Manager (RM) is a committer who volunteers to produce a Release Candidate according to HowToRelease. Project Management Committee Deciding what is distributed as products of the Apache Hadoop project. In particular all releases must be approved by the PMC Thanks, - Tsuyoshi On Mon, Jun 22, 2015 at 6:43 PM, Akira AJISAKA wrote: Hi everyone, In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that Apache Hadoop developers at Yahoo!, Twitter, and other non-distributors work very hard to maintenance Hadoop by cherry-picking patches to their own branches. I want to share the work with the community. If we can cherry-pick bug fix patches and have more maintenance releases, it'd be very happy not only for users but also for developers who work very hard for stabilizing their own branches. To have more maintenance releases, I propose two changes: * Major/Minor/Trivial bug fixes can be cherry-picked * (Roughly) Monthly maintenance release I would like to start the work from branch-2.6. If the change will be accepted by the community, I'm willing to work for the maintenance, as a release manager. Best regards, Akira -- Karthik Kambatla Software Engineer, Cloudera Inc. http://five.sentenc.es
Re: [DISCUSS] More Maintenance Releases
Thanks Karthik for the comment. I'm +1 for your approach to ensure stability. On 6/22/15 23:50, Karthik Kambatla wrote: Thanks for starting this thread, Akira. +1 to more maintenance releases. More stable upstream releases avoids duplicating cherry-pick work across consumers/vendors, and shows the maturity of the project to users. I see value in backporting blocker/critical issues, but have mixed feelings about doing the same for major/minor/trivial issues. IMO, every commit has non-zero potential to introduce other bugs. Depending on the kind of fix (say, documentation), it might be okay to include these non-critical fixes. One approach could be to allow all bug fixes for 2.x.1, blocker/critical for 2.x.2, blocker for 2.x.3 (or something along those lines) to ensure increasing stability of maintenance releases? I am also +1 to any committer picking up RM duties for a maintenance release. It is healthy to have more people participate in the release process, so long as we have some method to maintenance release madness. A committer (who is not yet a PMC member) could be a Release Manager, but his vote is not binding for the release. I RM-ed the 2.5.x releases as a committer. RM-ing a release and voting non-binding could be a good way to remind the PMC to include the committer in PMC :) Cheers Karthik On Mon, Jun 22, 2015 at 4:36 AM, Tsuyoshi Ozawa wrote: Hi Akira, Thank you for starting interesting topic. +1 on the idea of More Maintenance Releases for old branches. It would be good if this activity is more coupled with Apache Yetus for users. BTW, I don't know one of committers, who is not PMC, can be a release manager. Does anyone know about this? It's described in detail as follows: http://hadoop.apache.org/bylaws#Decision+Making Release Manager A Release Manager (RM) is a committer who volunteers to produce a Release Candidate according to HowToRelease. Project Management Committee Deciding what is distributed as products of the Apache Hadoop project. In particular all releases must be approved by the PMC Thanks, - Tsuyoshi On Mon, Jun 22, 2015 at 6:43 PM, Akira AJISAKA wrote: Hi everyone, In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that Apache Hadoop developers at Yahoo!, Twitter, and other non-distributors work very hard to maintenance Hadoop by cherry-picking patches to their own branches. I want to share the work with the community. If we can cherry-pick bug fix patches and have more maintenance releases, it'd be very happy not only for users but also for developers who work very hard for stabilizing their own branches. To have more maintenance releases, I propose two changes: * Major/Minor/Trivial bug fixes can be cherry-picked * (Roughly) Monthly maintenance release I would like to start the work from branch-2.6. If the change will be accepted by the community, I'm willing to work for the maintenance, as a release manager. Best regards, Akira
Re: [DISCUSS] More Maintenance Releases
Thank you for clarification, Karthik. I'd also like to work on stable release management with community. I'm thinking of speedy release against branch for making community feedback faster (e.g. current next version is 2.8, so cherry-picking to 2.7 and releasing it are useful work for users). I know that code base of 2.7.1 is now freezing currently, I'd love to work from 2.7.2 release if possible. Cheers, - Tsuyoshi On Tue, Jun 23, 2015 at 5:02 AM, Colin P. McCabe wrote: > +1 for creating a maintenance release with a more rapid release > cadence and more effort put into stability backports. I think this > would really be great for the project. > > Colin > > On Mon, Jun 22, 2015 at 2:43 AM, Akira AJISAKA > wrote: >> Hi everyone, >> >> In Hadoop Summit, I joined HDFS BoF and heard from Jason Lowe that Apache >> Hadoop developers at Yahoo!, Twitter, and other non-distributors work very >> hard to maintenance Hadoop by cherry-picking patches to their own branches. >> >> I want to share the work with the community. If we can cherry-pick bug fix >> patches and have more maintenance releases, it'd be very happy not only for >> users but also for developers who work very hard for stabilizing their own >> branches. >> >> To have more maintenance releases, I propose two changes: >> >> * Major/Minor/Trivial bug fixes can be cherry-picked >> * (Roughly) Monthly maintenance release >> >> I would like to start the work from branch-2.6. If the change will be >> accepted by the community, I'm willing to work for the maintenance, as a >> release manager. >> >> Best regards, >> Akira
