On Wednesday 11 April 2007 00:20, Steen wrote: > Tirsdag 10 april 2007 23:14 skrev Kern Sibbald: > > 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 logic I see sugested here is that if a request is only supported by very > few people, it is only realized if they can provide a patch - fair enough > > > > 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). > Fine > > 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). > This seems to mean that all three requirements should be fulfilled in order to > accept a feature request - which contradicts the initial remarks and the > consequense seems to be that only developer type of people can request > something, since they are the ones that can provide patches. > > So you must mean that only one of the three requirements must be fulfilled in > order to accept a patch - right?
Yes, sort of. As Arno pointed out, if a developer really wants a feature it is likely to go it. As project manager, I reserve two "prerogatives" for myself, that permit at least some control over the project. The two are really one and the same, but with a small nuance. 1. If I think a feature is really needed, I can put it in the projects list. 2. If I think a feature should not go into Bacula, I can veto it, giving a reason. I don't use the veto very often, but there are times when the requests would change the fundamental philosophy of Bacula -- e.g. put *all* the conf files in the catalog, or remove the central management in the Director by moving the responsibility for what files to backup to the FD, ... Often, the request will have unacceptable, confusing or inconsistent use of directives or syntax which would seriously mess up the "certain" consistency we have. In those cases, it is normally a matter of finding a solution, as we recently did with Eric's suggestion for regex wheres (I think everyone got what he wanted in the end). Finally, there are requests that I feel are impossible to implement -- such as the recent one to predict future pruning. There is *nothing* different in the above from what I have been doing for 7 years now, it is just becoming a bit more formalized. To summarize the points: 1. The project manager can veto a feature request with good reason (often but not always the request can still be negotiated). 2. The project manager can add project that he feels are important to Bacula's advancement. 3. Users may submit feature requests, which can be accepted by point 2 above, or acquire enough votes (probably 6-10) to be put into the projects list. 4. A feature request can be submitted with a patch, which providing it passes item 1 above will be implemented. 5. A developer can assume the responsibility for implementing a feature request, which is in fact essentially identical to point 4 above. After thinking about this a bit more, what I have decided to do it to put all features which fall into item 3 (i.e. submitted but not approved by the project manager and not having sufficient votes) will go into pending-features, so they will not be lost. Pending-features will not participate in the voting process. As always, any additional comments are welcome. Best regards, Kern > > in that case it seems to me a good practical way to balance things. > > > > 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 > > -- > Regards > > Steen > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
