Although, I am really pleased at seeing lots of people using Bacula, and interest in improving it, we seem to be getting a lot of Feature Requests. In fact, given our currently very limited programming resources, I feel we have way too many feature requests.
The last time we voted, there were 40, which seems to me to be way too many. In the end, it makes it hard to vote, and many of the requests, IMO are unlikely to ever be implemented because they are desired only by one or two people, and they for many reasons (lack of skills, lack of time, ...) cannot contribute the patch. The last thing in the world I want to do is to "censure" any feature request, unless I think it is impossible to implement (then all you need to do is provide a algorithm). Nor do I want to discourage ideas or feature requests, but in an effort to keep the projects list to a reasonable number, I propose the following new procedure for getting a feature request accepted into the projects file: 1. I think the feature request is really required or has some special merit. 2. There are at least six responses that vote for including the feature request. 3. The feature request is accompanied by a patch (it is always better to check whether the feature is likely to be accepted before spending any great time on patches). The above is actually how it is documented on the web site, but maybe not very clearly). If anyone has any problems with this new way of trying to deal with the large number of requests, please speak up now. On Tuesday 10 April 2007 21:29, Darien Hager wrote: > Item 1: Allow Jobdefs to inherit from other Jobdefs > Origin: Darien Hager <[EMAIL PROTECTED]> > Date: Date submitted (e.g. 28 October 2005) > Status: Initial Request > > What: Allow JobDefs to inherit/modify settings from other JobDefs > > Why: Makes setting up jobs much easier for situations with many > clients doing similar work > > Notes: > > Example: User has several JobDefs which all need Messages=standard, > Type=Backup, and settings for "Rerun Failed Levels" and "Max * Time". > This feature would allow those "common" properties to be within a > single JobDef which each child JobDefs inherits from, before the > final Job definitions sets further specifics such as Client. > > Currently the documentation leaves open the possibility that this can > be done, but tests with Bacula 2.0.1 suggest that JobDefs entries > cannot themselves have a JobDefs property. > > Technical caveat: Should probably include rudimentary checks against > a cyclic relationship, such as a limit to the number of allowed layers. > > See also: "Job Groups or hierarchy" Feb 6 2007 > > > > -- > --Darien A. Hager > [EMAIL PROTECTED] > > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
