Hello Vitaly, Nice to hear from you :-)
On Friday 23 July 2010 21:21:59 Vitaly Kuznetsov wrote: > Kern Sibbald <k...@sibbald.com> writes: > > 2. New release cycle: > > The little code we currently have for the next major release is in the > > SF bacula git repository under Branch-5.1. > > > > We are considering to moving to a regular 6 month release cycle. The > > advantage of such a cycle is that it gets features out to you faster. > > The disadvantage is that it doesn't work so well in small projects like > > Bacula if there are not sufficient contributions. > > > > Such a release would consist of the following points: > > > > - A release every 6 months > > - The deadline is not absolute and could be extended to 9 months if there > > were insufficient new submissions. > > - There will be far fewer or no bug fix updates as they are not really > > needed if we can maintain a 6 month cycle. > > It seems to me that 6-month cycle is ok for new features (maybe it's too > short and 9-12 month cycle will be better), but it's too long for > bugfixes. Yes, 6 months is too short if you have Bacula in production, and if Bacula were not stable. However, it is quite a nice cycle (IMO) if you have stable releases and things are moving forward and your site is not too large. From what I have heard and read, it does amazing things for motivating more contributions. If larger users were to upgrade every other release, that would prove to be a nice cycle. > Maybe it would be better to separate this things (I'm not insisting, of > course), e.g. > > New major release with new features: every 9-12 months > New minor release with bugfixes only: every month (if needed). This is what we will be doing for the Enterprise version (the major new release cycle will be 12-18 months), but it is not appropriate for a development project. First 12 months is a very long time for a developer to wait to see his code go in, and second as non-paid volunteers you are *very* unlikely to find anyone who will want to release once a month -- unless you are talking about a small non-critical program, which is not at all the case for Bacula. > > The disadvantage is: it's required to separate git branches for bugfixes > and features (minor/major). > > This approach only matters if there will be enough bugfixes and new > features for the community branches. I believe that the bug fixes and new features for the community branches will slow down enormously in the next few years, unless the Bacula community organizes itself more that currently is the case. This is principally because until recently, I was the major person adding new features and doing bug fixes. In fact, there have been only a tiny percentage of the bugs fixed by the community. I have been now doing this for 10.5 years (8+ from the time it was publicly released). More and more the important bugs are reported by *very* large users. Since I am now focusing on getting Bacula into Enterprises -- i.e. adding very high end features, once the new bugs database is up, I will no longer have time fix many bugs for the community unless they are serious -- the community will need to find bug fixers or wait until the next release -- this is how all other projects that I know work. So, I will be there to help all I can, but I am going to progressively turn over this part of what I have been doing to the community. The community has been an *enormous* help in getting Bacula to where it is, and will continue to do so, I am sure. However, integrating community contributions is very difficult as often they need to be totally rewritten and sometimes even redesigned from the ground up. This is probably because of several things: 1. I have high standards, which slow down development a bit in the short run, but speed it enormously in the long run, and ensure the stability of Bacula (a critical component of large scale computing). 2. The community submissions are most often made without consulting with us before implementing and by people who are not very experienced in Bacula programming. The ideas embodied in their submissions are, in general, excellent, but the execution more often than not lacks. Hopefully, we can find more experienced community developers to work on accepting patches and reworking them so they are appropriate to go into Bacula. I believe that the long term future of Bacula is tightly coupled with the success of Bacula Systems, so I am devoting a big effort in that direction. Thanks for your comments. I hope my responses make sense to you. Kern ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
