Re: [Ganglia-developers] autotools / git release branches / web version.php
On Mon, Mar 26, 2012 at 04:57:31PM +0100, Daniel Pocock wrote: Having the option to work both ways may just continue to create traps for people who know one half of the project and not so much about the other. ironically, the main driver for the 3.3.x series was to import the new web frontend, and it used to (mostly) work for the first 2 releases of that series while keeping the posibility of building independently. it would seem IMHO that all the extra hacking that was done to the build and release process, including the (mostly ignored) documentation hadn't improved on its reliability or clarity as shown by the fact that the last package release just masquerades the obsolete version 3.3.1 as 3.3.5 for web. Carlo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] release/3.3 branch created
I've created a new branch in git for 3.3 releases: https://github.com/ganglia/monitor-core/branches/release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git pull Already up-to-date. daniel@lt2:~/ws/ganglia/ganglia-git$ git branch release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git branch * master release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git push origin release/3.3 Total 0 (delta 0), reused 0 (delta 0) To ssh://g...@github.com/ganglia/monitor-core.git * [new branch] release/3.3 - release/3.3 Further 3.3.x releases should be made from the branch, and tags should be made on the branch (I've updated the release procedure with comments about this) Any bug fixes or new features should continue to go on master, and then they can be selectively merged into the release branch if necessary. I would propose that the merge policy is not too restrictive: while a tarball is in release candidate status (e.g. 3.3.5 at present), only the release manager should merge/backport from master. At all other times, any committer can merge bug fixes onto the release branch. I'd also propose the same for the web repo, but I haven't created any branch there yet as I'd like to get feedback on the strategy first -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] autotools / git release branches / web version.php
On 27/03/2012 10:05, Carlo Marcelo Arenas Belon wrote: On Mon, Mar 26, 2012 at 04:57:31PM +0100, Daniel Pocock wrote: Having the option to work both ways may just continue to create traps for people who know one half of the project and not so much about the other. ironically, the main driver for the 3.3.x series was to import the new web frontend, and it used to (mostly) work for the first 2 releases of that series while keeping the posibility of building independently. Those releases worked for some people and not others Another idea: the web tree can have Makefile.am, managed by monitor-core/configure.in and that can be the official release and packaging mechanism But for those who want to make standalone builds, the web/Makefile can be renamed as web/Makefile.standalone and executed manually make -f Makefile.standalone it would seem IMHO that all the extra hacking that was done to the build and release process, including the (mostly ignored) documentation hadn't improved on its reliability or clarity as shown by the fact that the last package release just masquerades the obsolete version 3.3.1 as 3.3.5 for web. It has resulted in a review of past processes, more wiki documentation, and I think we have now reached the point where I can build the Solaris packages again, these are all good outcomes that the project can build on -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] release/3.3 branch created
I don't really see a point in branching at this point. We have so few commiters and commits that having to maintain separate branches is at this time unwarranted. If this becomes an issue in the future I would address it at that time. Vladimir On Tue, 27 Mar 2012, Daniel Pocock wrote: I've created a new branch in git for 3.3 releases: https://github.com/ganglia/monitor-core/branches/release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git pull Already up-to-date. daniel@lt2:~/ws/ganglia/ganglia-git$ git branch release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git branch * master release/3.3 daniel@lt2:~/ws/ganglia/ganglia-git$ git push origin release/3.3 Total 0 (delta 0), reused 0 (delta 0) To ssh://g...@github.com/ganglia/monitor-core.git * [new branch] release/3.3 - release/3.3 Further 3.3.x releases should be made from the branch, and tags should be made on the branch (I've updated the release procedure with comments about this) Any bug fixes or new features should continue to go on master, and then they can be selectively merged into the release branch if necessary. I would propose that the merge policy is not too restrictive: while a tarball is in release candidate status (e.g. 3.3.5 at present), only the release manager should merge/backport from master. At all other times, any committer can merge bug fixes onto the release branch. I'd also propose the same for the web repo, but I haven't created any branch there yet as I'd like to get feedback on the strategy first -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] release/3.3 branch created
On 27/03/2012 14:52, Vladimir Vuksan wrote: I don't really see a point in branching at this point. We have so few commiters and commits that having to maintain separate branches is at this time unwarranted. If this becomes an issue in the future I would address it at that time. Actually, it is not about the number of committers It just makes organisation easier: we need to lock things down for a release branch (e.g. 3.3.x series). The more features and other improvements that `creep' into the releases, the more difficult the release cycle will be. If 3.3.5 is good, then no new features should be added to the branch (either in monitor-core or web), only essential bug fixes. After a whole lot of new features accumulate on master, just do: git branch release/3.4 git checkout release/3.4 git tag -m 'Tag 3.4.0' 3.4.0 and the features get released in 3.4 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] release/3.3 branch created
I understand that. What I am trying to say is that it adds complexity since you have to merge things back to branches test it etc. This adds additional overhead to our already thin resources. We had a 3.0 branch and there was talk of needing to release 3.0.8 but it never came about due to lack of resources/disinterest. Therefore I'd like to dump branches for now and just stay on mainline. Vladimir On Tue, 27 Mar 2012, Daniel Pocock wrote: On 27/03/2012 15:28, Vladimir Vuksan wrote: In my mind it doesn't. It just adds the job of merging down the line. I prefer to work on the trunk since that forces you to actually make things work and not defer changes since you have them sitting on a branch. I understand there are pros and cons to both approaches. I just don't see that as a problem that needs to be solved at this time. I would prefer we spent our time of fixing/improving things instead of process. I am only talking about release branches, not feature branches A feature branch is something I create (e.g. to overhaul the autotools stuff) and I am responsible for merging that in to master (trunk) later when I think it is ready. Thanks to the wonders of git, people are free to do that if and when they please. In contrast, a release branch basically draws a line underneath a minor release (e.g. 3.3 series). It never has to be merged back to master. Typically, bug fixes are done on master, and then the bug fix is selectively merged into the release branch, but only if it meets certain criteria: - only if the bug fix relates to the release - only if the bug is over some threshold of severity Example timeline: new feature A branch 3.3 release 3.3.0 new feature B branch 3.4 release 3.4.0 find and fix bug in B (b1) release 3.4.1 find and fix bug in A (b2) release 3.3.1 and 3.4.2 In the above example, notice that nobody has to bother merging the fix for (b1) back into the release/3.3 branch -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] release/3.3 branch created
On Tue, Mar 27, 2012 at 10:46:51AM -0400, Vladimir Vuksan wrote: Therefore I'd like to dump branches for now and just stay on mainline. +1, keep it simple; and unless my view of git log is incorrect no feature (except some bugfixes) were added since 3.3.2 anyway, which might be the reason why the last release notes available (and that has already a due date that is 1 month old) hasn't been updated : https://github.com/ganglia/monitor-core/wiki/Release-Notes Carlo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] 3.3.5 tagged
On Mon, Mar 26, 2012 at 04:50:18PM +0100, Daniel Pocock wrote: Release 3.3.5 The release has now been tagged in git commit = 9db9beea062c7ce5e5b4d10ed553c9b7cea7642e wrong bundle : carenas@dell ~/src/git/ganglia $ git describe --tags 3.3.5 carenas@dell ~/src/git/ganglia $ cd web/ carenas@dell ~/src/git/ganglia/web $ git describe --tags 3.3.2-3 while web has since had a lot more fixes added as shown by : carenas@dell ~/src/git/ganglia-web $ git describe --tags 3.3.4-14-g7383ed8 carenas@dell ~/src/git/ganglia-web $ git diff --stat 3.3.2-3.. | cat Makefile |2 +- api/host.php |9 ++--- cluster_view.php |4 ++-- functions.php| 15 +++ graph.php|5 +++-- header.php |1 + inspect_graph.php|4 ++-- templates/default/views_view.tpl | 16 8 files changed, 42 insertions(+), 14 deletions(-) Carlo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] release/3.3 branch created
On 27/03/2012 16:45, Carlo Marcelo Arenas Belon wrote: On Tue, Mar 27, 2012 at 10:46:51AM -0400, Vladimir Vuksan wrote: Therefore I'd like to dump branches for now and just stay on mainline. +1, keep it simple; and unless my view of git log is incorrect no feature (except some bugfixes) were added since 3.3.2 anyway, which might be the reason why the last release notes available (and that has already a due date that is 1 month old) hasn't been updated : https://github.com/ganglia/monitor-core/wiki/Release-Notes I think we should look at the lifecycle of Ganglia in relation to the larger packaging efforts (e.g. Debian has a 2 year lifecycle for each stable release, RHEL is similar, and I hear they are currently deciding what to accept for their next major release) - are there likely to be minor feature releases of Ganglia (e.g. 3.4.x and 3.5.x) during the time that 3.3.x is still kicking about in stable distributions of Debian (if the next Debian comes this year, it will live until at least 2014)? - if so, what is the procedure to release bug fixes for those distributions? If a release branch solves this problem, I think it is a good idea Think about the alternative, each distribution (e.g. Debian, OpenCSW) also has their own repo for tracking local patches. Do we really want a situation where bug fixes start accumulating in those third-party repos, where users on different platforms have different sets of bug fixes, etc? Also, I think the branch name release/3.3 is a common pattern for git repositories, it is not unique to Ganglia, so it doesn't really require a special effort for people to learn how it works if they have used this pattern on another project. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] 3.3.5 tagged
On 27/03/2012 16:52, Carlo Marcelo Arenas Belon wrote: On Mon, Mar 26, 2012 at 04:50:18PM +0100, Daniel Pocock wrote: Release 3.3.5 The release has now been tagged in git commit = 9db9beea062c7ce5e5b4d10ed553c9b7cea7642e wrong bundle : carenas@dell ~/src/git/ganglia $ git describe --tags 3.3.5 carenas@dell ~/src/git/ganglia $ cd web/ carenas@dell ~/src/git/ganglia/web $ git describe --tags 3.3.2-3 while web has since had a lot more fixes added as shown by : carenas@dell ~/src/git/ganglia-web $ git describe --tags 3.3.4-14-g7383ed8 carenas@dell ~/src/git/ganglia-web $ git diff --stat 3.3.2-3.. | cat Makefile |2 +- api/host.php |9 ++--- cluster_view.php |4 ++-- functions.php| 15 +++ graph.php|5 +++-- header.php |1 + inspect_graph.php|4 ++-- templates/default/views_view.tpl | 16 8 files changed, 42 insertions(+), 14 deletions(-) Does this result in any actual breakage: does 3.3.5 break anything that was working in 3.3.1 or 3.3.0? If the answer to that question is `no', then we ignore this issue and 3.3.5 continues to be the release candidate. Are these all fixes that belong in the 3.3.x release, or are some of them features that belong in 3.4.x? I am not automatically increasing the pointer to the web submodule because I think that only crucial things should be accepted in 3.3.x releases from now on - the alternative is that a) we freeze the web repo against all non-essential commits until the release is finally finished b) I update the pointer to the web repo on every 3.3.x release attempt -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
[Ganglia-developers] roadmap / objectives
Google found this: http://sourceforge.net/apps/trac/ganglia/roadmap Therefore, I decided to write down what I had in mind when proposing the 3.3.x releases: https://github.com/ganglia/monitor-core/wiki/Roadmap I think this higher level roadmap provides a good background for any discussions about branches, things missed in the release, etc However, it is only a summary of what I have in mind myself: do people agree on these things? Or should it be changed? -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] 3.3.5 tagged
I thought the original idea was that the web component was going to be a separate entity and thus can be released at different cycles from the other components. If we are again releasing web at the same time as ganglia-core then this is back to how things were originally when the code is in SVN. Just my $0.02. Cheers, Bernard On Tuesday, March 27, 2012, Daniel Pocock dan...@pocock.com.au wrote: On 27/03/2012 16:52, Carlo Marcelo Arenas Belon wrote: On Mon, Mar 26, 2012 at 04:50:18PM +0100, Daniel Pocock wrote: Release 3.3.5 The release has now been tagged in git commit = 9db9beea062c7ce5e5b4d10ed553c9b7cea7642e wrong bundle : carenas@dell ~/src/git/ganglia $ git describe --tags 3.3.5 carenas@dell ~/src/git/ganglia $ cd web/ carenas@dell ~/src/git/ganglia/web $ git describe --tags 3.3.2-3 while web has since had a lot more fixes added as shown by : carenas@dell ~/src/git/ganglia-web $ git describe --tags 3.3.4-14-g7383ed8 carenas@dell ~/src/git/ganglia-web $ git diff --stat 3.3.2-3.. | cat Makefile |2 +- api/host.php |9 ++--- cluster_view.php |4 ++-- functions.php| 15 +++ graph.php|5 +++-- header.php |1 + inspect_graph.php|4 ++-- templates/default/views_view.tpl | 16 8 files changed, 42 insertions(+), 14 deletions(-) Does this result in any actual breakage: does 3.3.5 break anything that was working in 3.3.1 or 3.3.0? If the answer to that question is `no', then we ignore this issue and 3.3.5 continues to be the release candidate. Are these all fixes that belong in the 3.3.x release, or are some of them features that belong in 3.4.x? I am not automatically increasing the pointer to the web submodule because I think that only crucial things should be accepted in 3.3.x releases from now on - the alternative is that a) we freeze the web repo against all non-essential commits until the release is finally finished b) I update the pointer to the web repo on every 3.3.x release attempt -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
