On Tuesday 27 July 2010 12:21:01 Pasi Kärkkäinen wrote:
> On Fri, Jul 23, 2010 at 05:54:03PM +0200, Kern Sibbald wrote:
> > 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
>
> Hopefully this means 'major' release every 6 months.
It means a release irrespective if it is a bug fix, a minor, or a major
release. There are probably not enough submissions to do a major release
every six months, which is why I suggested it could be extended to 9 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.
>
> I've read your comments about this from the other emails, but I think it's
> important to release new *minor* versions for known/important bugs,
> assuming the fixes are available.
Yes, I agree with you, but someone other than me, in many cases, will need to
do it. That is someone in the community will need to step forward to do more
frequent releases. I have been releasing Bacula for more than 8 years now,
and the project has grown sufficiently large, and it is also quite stable. I
no longer have the time or energy to make more frequent releases. If you
look at the past release history, I doubt that we ever released more
frequently than a six month cycle on the average.
If you want releases more frequently that fix bugs, then you can get them from
Bacula Systems -- they have trained people to do this, but they are on salary
and so it costs money to make the releases, which means there is a price.
>
> > - Two months before the projected release we will decide if there are
> > sufficient new features to release
> > - The release count down will consist of 3 phases
> > 1. We will add all new approved features
> > The first 4 months after a release this phase will go into
> > effect for the next release
> > - 2. Only very small new features (a few lines) will be added
> > Two months before the final release this phase will go into
> > effect. Note, this phase can be delayed 3 months if
> > insufficient new features are submitted
> > 3. Only bug fixes
> > This phase will go into effect one month before the release
> >
> > Under this scheme, we are currently in Phase 3 for the 5.0.3 release, and
> > the next major release (5.2.0) would be made before mid-January 2011, and
> > is currently under development in Branch-5.1 on Source Forge.
>
> So if 5.0.3 ends up having some bad bug, 5.0.4 should be released before
> 5.2.0.
That is the way it used to work. It may not work that way in the future. The
definition of a "bad" bug is up to me as long as it is me doing the work for
free, and since I am overloaded with work, I won't be very inclined to
release something that has a workaround. Doing a release is at least 8 hours
of work, and often much more.
As I mentioned above, if there are other people in the community who want to
take up this workload and do more frequent releases, then I don't see any
problem.
>
> ie. use most development efforts on the major/master branch,
> but still maintain stable branch.
This is the way we have always worked, and I don't see, at least at this time,
any reason to change.
Thanks for your comments,
Kern
>
> -- Pasi
>
> > I would appreciate comments on this proposed new "deadline" release
> > cycle.
> >
> > 3. New bugs tracking database
> > Sometime in early August (possibly slightly before) we will be moving the
> > current Mantis based bug tracking system to a new RT based system hosted
> > by Bacula Systems. The upside is that the RT system is far more
> > powerful, flexible and adaptible, and most important of all, it allows
> > email responses to bugs. The downside is that it is a bit more
> > complicated (as are most things that have more features) and that it will
> > require everyone to re-register for the new system. In addition, if you
> > don't want to rely on just the community to furnish bug fixes, you will
> > be able to subscribe to a bug fix service that is more professional and
> > has a guaranteed response time (not to be mistaken for a guaranteed fix
> > time). More on this when the service is ready for production.
> >
> > 4. New Bacula server
> > The current Bacula Community server is as you probably know generously
> > offered by UKFast. However, the hardware is starting to age, so they
> > have gratiously provided us with a new machine that we will be putting in
> > place in the next few weeks. We don't expect that you will notice any
> > differences, but the hardware running www.bacula.org should be more
> > stable.
> >
> > 5. New Bacula source distribution server
> > You may or may not be aware that we have not always been pleased with the
> > services offered by Source Forge. The uploading is complicated by lines
> > dropping (I have *never* seen this else where), their user interface is
> > horrible, we don't get good statistics, being US based, they block direct
> > access to our code from a number of countries such as Cuba, ... So,
> > probably in September or October we will be moving our Bacula project off
> > of Source Forge to a new server provided by UKFast. There is still a
> > *lot* of work to be done to make this work -- principally getting up a
> > good and suitable interface for users -- more as this develops.
> >
> > As mentioned above, I would appreciate any comments you might have,
> > particularly on the proposed new release cycle.
> >
> > Best regards,
> >
> > 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 AT lists.sourceforge DOT net
> > https://lists.sourceforge.net/lists/listinfo/bacula-devel
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
