Correct, all of my changes should remain in trunk only. The only change in this list that is not mine is revision 765 by massie
Brad >>> On 5/16/2007 at 6:29 PM, in message <[EMAIL PROTECTED]>, "Bernard Li" <[EMAIL PROTECTED]> wrote: > Dear all: > > I went ahead and backported most of my changes to trunk which should > also go into the 3.0.x branch. Since the branch was created at > revision 747, I scanned for changes in trunk after 747 up until > earlier today. The following are changes I am not sure whether they > should go into branch as well: > > Revision 778 - Directory Listing > Modified Mon May 7 20:30:47 2007 UTC (9 days, 1 hour ago) by bnicholes > > Fix a double free issue with when destroying memory pools > > Revision 777 - Directory Listing > Modified Fri May 4 22:27:06 2007 UTC (11 days, 23 hours ago) by bnicholes > > Add modules/cpu to the build > > Revision 776 - Directory Listing > Modified Fri May 4 22:26:12 2007 UTC (11 days, 23 hours ago) by bnicholes > > Add a multi cpu module that will dynamically create metric gathering > function depending on the number of cpus found in the system > > Revision 774 - Directory Listing > Modified Fri May 4 22:14:47 2007 UTC (11 days, 23 hours ago) by bnicholes > > Add a memory pool parameter to the module init function > > Revision 773 - Directory Listing > Modified Wed May 2 22:14:28 2007 UTC (13 days, 23 hours ago) by bnicholes > > rework the interface for the metric modules so that a single module > can gather multiple metrics. This also allows the metric names to be > different from the module name. Use the -m commandline parameter to > discover the names of the metrics that the metric module supports. > > Revision 765 - Directory Listing > Modified Thu Apr 26 05:02:01 2007 UTC (2 weeks, 6 days ago) by massie > > [Bug 136] gmetric does not allow slope to be set correct > > fixed by Nick Galbreath <[EMAIL PROTECTED]> > > > Revision 759 - Directory Listing > Modified Fri Apr 6 20:08:01 2007 UTC (5 weeks, 5 days ago) by bnicholes > > Change the name of the module to reflect that it is a plugin module > rather than a linkable library. Also put the modules in lib/ganglia > directory to avoid name collisions in the lib directory > > Revision 758 - Directory Listing > Modified Fri Apr 6 20:05:28 2007 UTC (5 weeks, 5 days ago) by bnicholes > > Add an example configuration file that loads and configures the example > module > > Revision 756 - Directory Listing > Modified Thu Apr 5 14:52:14 2007 UTC (5 weeks, 6 days ago) by bnicholes > > add the missing integer value to the user defined metric definition > > Revision 752 - Directory Listing > Modified Mon Apr 2 23:20:38 2007 UTC (6 weeks, 1 day ago) by bnicholes > > minor cleanups > > Revision 751 - Directory Listing > Modified Mon Apr 2 22:55:23 2007 UTC (6 weeks, 1 day ago) by bnicholes > > Add a metric description to the output of the -m parameter as well as > to the XML output. > > Revision 750 - Directory Listing > Modified Mon Apr 2 22:12:58 2007 UTC (6 weeks, 1 day ago) by bnicholes > > Modify the -m parameter to also list the loaded modular metrics > > I am assuming that the Brad's checkins regarding 'modules' should be > left in trunk? > > If the owners of the above check-ins can either backport them to > branch or simply let me know that they should go in, I will take care > of it. > > Afterwards, I will check in my fixes for ganglia.spec.in. > > Thanks for all your help! > > Cheers, > > Bernard > > On 5/16/07, Brad Nicholes <[EMAIL PROTECTED]> wrote: >> As you stated, everything that I have done should remain in trunk only. > I would imagine that almost everything else committed to trunk could be > backported to the 3.0.x branch if desired. >> >> Brad >> >> >>> On 5/16/2007 at 4:06 PM, in message >> <[EMAIL PROTECTED]>, "Bernard Li" >> <[EMAIL PROTECTED]> wrote: >> > Do we currently have plans for Ganglia 3.0.5 release? I would >> > personally like to see a release very soon -- we have made a few >> > enhancements to the webfrontend plus other cleanups to the code. >> > Also, given our developer base, we should probably wrap up 3.0.x >> > branch and start focusing on 3.1.x (unless we have other plans for >> > 3.0.x branch). >> > >> > However, it looks like since the branch was created, most changes were >> > still done to trunk (my changes included). Can we agree on what >> > changes should go into 3.0.x branch vs trunk? >> > >> > I would think that all the dynamically link libraries work which Brad >> > has been working on should stay in trunk -- however, if there are >> > conflicting changes done to the branch, they should be reverted. >> > >> > I could try to go through my recent changes and make sure that they go >> > into the branch as well -- I hope that other developers can do the >> > same. >> > >> > Makes sense? >> > >> > Thanks in advance, >> > >> > Bernard >> > >> ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
