From: Daniel P. <da...@po...> - 2012-03-27 15:53:56
|
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. |