I tried `make dist' for a possible 3.3.2 release, there are some
differences in the fileset
I don't think all of them are essential to the release, but I'm
publishing it here so people can have a quick look and make any comments
I already notice the web/.git stuff - I'll exclude that from
I've updated the document at
https://github.com/ganglia/monitor-core/wiki/BuildingARelease
and been able to follow the steps there to build a working tarball (at
least the tarball works for me).
The main change is that it now relies on `make dist' rather than
scripts/package-ganglia-release
On 20/03/2012 11:54, Daniel Pocock wrote:
I tried `make dist' for a possible 3.3.2 release, there are some
differences in the fileset
I don't think all of them are essential to the release, but I'm
publishing it here so people can have a quick look and make any comments
I already notice
On 20/03/2012 12:09, Daniel Pocock wrote:
I've updated the document at
https://github.com/ganglia/monitor-core/wiki/BuildingARelease
and been able to follow the steps there to build a working tarball (at
least the tarball works for me).
The main change is that it now relies on `make
I tested the tarball and it still does not contain the following files:
ganglia-3.3.2/ChangeLog
ganglia-3.3.2/libmetrics/ChangeLog
ganglia-3.3.2/libmetrics/INSTALL
Those files are necessary if you do a autoreconf -fi which is
necessary if you add something to any *.am file in the source tree. I
Besides the autoreconf issue I mentioned in my previous email, the
tarball compiles cleanly on
AIX5.1, AIX5.3, RHEL4, RHEL6, SLES9, SLES10, SLES11
Regards,
Michael
On 03/20/2012 03:07 PM, Daniel Pocock wrote:
On 20/03/2012 12:09, Daniel Pocock wrote:
I've updated the document at
Hi Daniel:
If you let me know where you put the tarballs I will put them in
http://ganglia.info/downloads/testing.
Cheers,
Bernard
On Tuesday, March 20, 2012, Daniel Pocock dan...@pocock.com.au wrote:
I've updated the document at
On Tue, Mar 20, 2012 at 12:09:29PM +, Daniel Pocock wrote:
Does anyone want to sneak in any last minute changes before I tag 3.3.2
and make the tarball available for testing?
there is already a published tag named 3.3.2, if you are not going to release
that then it will be better if we
Thanks for the prompt feedback
I understand from your email that you are not worried if those files are
empty?
Maintaining extra copies of these files for libmetrics may be another
reason to try and avoid the nested configure script
On 20/03/2012 15:07, Michael Perzl wrote:
I tested the
On 20/03/2012 16:32, Carlo Marcelo Arenas Belon wrote:
On Tue, Mar 20, 2012 at 12:09:29PM +, Daniel Pocock wrote:
Does anyone want to sneak in any last minute changes before I tag 3.3.2
and make the tarball available for testing?
there is already a published tag named 3.3.2, if you are
Michael's request for ChangeLog and INSTALL files mentions a requirement
to re-bootstrap the source tree (using autoreconf to regenerate Makefiles)
Some time ago we had a discussion where it was decided that the
autotools product versions in Debian 6.0 (squeeze) would be the official
On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocock dan...@pocock.com.au wrote:
I agree with that approach, with a slight variation - I'll tag it as
3.3.3dp1 (after adding the ChangeLog file)
Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1 - 3.3.3?
Cheers,
Bernard
On 20/03/2012 17:34, Bernard Li wrote:
On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote:
I agree with that approach, with a slight variation - I'll tag it as
3.3.3dp1 (after adding the ChangeLog file)
Quick question -- does this prevent RPM upgrading? i.e. 3.3.3dp1
I've tagged a release candidate 3.3.3dp1
commit = c8531e5d57f6126eee6f47f1ad8734e86c1e9cb5
SHA-256
96cd90f2f978bb5e6c471798fa8d4b599a9910dfdae19bbfd7353abcb1497548
ganglia-3.3.3.tar.gz
The two changes from 3.3.2:
a) we are no longer calling it 3.3.2, because a tag already exists with
that
On Tue, Mar 20, 2012 at 05:36:56PM +, Daniel Pocock wrote:
On 20/03/2012 17:34, Bernard Li wrote:
On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote:
I agree with that approach, with a slight variation - I'll tag it as
3.3.3dp1 (after adding the ChangeLog file)
On Tue, Mar 20, 2012 at 13:36, Daniel Pocock dan...@pocock.com.au wrote:
On 20/03/2012 17:34, Bernard Li wrote:
On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au wrote:
I agree with that approach, with a slight variation - I'll tag it as
3.3.3dp1 (after adding the ChangeLog
On 20/03/2012 17:57, Jesse Becker wrote:
On Tue, Mar 20, 2012 at 13:36, Daniel Pocockdan...@pocock.com.au wrote:
On 20/03/2012 17:34, Bernard Li wrote:
On Tue, Mar 20, 2012 at 10:03 AM, Daniel Pocockdan...@pocock.com.au
wrote:
I agree with that approach, with a slight variation - I'll
I don't really want to make a big deal out of this but I thought it
was long agreed that we would tag a release (eg. 3.3.2) and that would
potentially be our Release Candidate. If everything is fine, we
will just release as is otherwise we will discard 3.3.2, bump the
version to 3.3.3 and repeat
On 20/03/12 19:27, Bernard Li wrote:
I don't really want to make a big deal out of this but I thought it
was long agreed that we would tag a release (eg. 3.3.2) and that would
potentially be our Release Candidate. If everything is fine, we
will just release as is otherwise we will discard
On Tue, Mar 20, 2012 at 14:52, Daniel Pocock dan...@pocock.com.au wrote:
On 20/03/12 19:27, Bernard Li wrote:
I don't really want to make a big deal out of this but I thought it
was long agreed that we would tag a release (eg. 3.3.2) and that would
potentially be our Release Candidate. If
On 20/03/12 19:59, Jesse Becker wrote:
On Tue, Mar 20, 2012 at 14:52, Daniel Pocock dan...@pocock.com.au wrote:
On 20/03/12 19:27, Bernard Li wrote:
I don't really want to make a big deal out of this but I thought it
was long agreed that we would tag a release (eg. 3.3.2) and that
a version number. And when they
do, IMO, it should be strictly date based--such as 20120320--instead
of an arbitrary version 1.0.
The RPM release, on the other hand, is strictly the purvue of the
packager, and indicates changes to the package that is distributed.
This can included updated metadata
On 03/20/2012 06:19 PM, Daniel Pocock wrote:
b) should Michael (or anyone else) need to modify Makefile.am from a
tarball? If there are regular changes to Makefile.am after releases are
made, shouldn't we find a way to incorporate such changes into trunk, or
provide more variables for people
On 03/20/2012 08:23 PM, Jesse Becker wrote:
If the Ganglia community releases a tarball called, 3.3.3-2.tar.gz, for
example, then someone building RPM packages might release 3.3.3-2-1
If the Ganglia project really did release 3.3.3-2.tar.gz, we should
have our heads examined. :)
But yes,
On 20/03/12 22:20, Michael Perzl wrote:
On 03/20/2012 06:19 PM, Daniel Pocock wrote:
b) should Michael (or anyone else) need to modify Makefile.am from a
tarball? If there are regular changes to Makefile.am after releases are
made, shouldn't we find a way to incorporate such changes into
25 matches
Mail list logo
