On Wednesday 09 November 2005 18:58, Karl Cunningham wrote: > Hi Kern -- > > Sounds like a great plan. It's probably too late but I suggest changing > the acronym from RFC to something else to avoid conflict and possible > confusion with RFC = "Request for Comment", used extensively to document > Internet and other standards. > > What about RFF = "Request for Feature"
Yes, the RFC, despite its original meaning is *actually* a feature request and also a standard's document. I can see that there might be some confusion, so why don't we just call it a "Feature Request"? > > Karl Cunningham > > Kern Sibbald wrote: > > Hello, > > > > A word about 1.38.0: > > Release 1.38.0 is evolving much as prior releases, that is to say, once > > people started to use it, we received a number of bug reports, some > > rather important. All the critical, serious, and important bugs have been > > fixed and if you want a copy, you can pull it from the Bacula CVS using > > branch Branch-1_38_0. If all continues normally, I'll release a version > > 1.38.1 this weekend which will contain fixes for all the currently known > > bugs. > > > > Concerning future development of Bacula: > > As I noted in the 1.38 ReleaseNotes, version 1.38 was different from > > prior versions because it had a lot more contributions. I expect that > > this trend will continue. As a consequence, I am going to modify how I > > normally do development, and instead of making a list of all the features > > that I will implement in the next version, I will personally sign up for > > one (maybe two) projects at a time, and when they are complete, I will > > release a new version. > > > > The difference is that I will have more time to review the new code that > > is being contributed, and will be able to devote more time to a smaller > > number of projects (1.38 had too many new features for me to handle > > correctly). > > > > I expect that future release schedules will be much the same, and the > > number of new features will also be much the same providing that the > > contributions continue to come -- and they show no signs of let up :-) > > > > Feature requests -- RFCs: > > In addition, I would like to "formalize" the feature requests (RFC) a > > bit. Instead of me maintaining an informal list of everything I run into > > (kernstodo), I would like to maintain a "formal" list of projects. This > > means that all new feature requests, including those recently discussed > > on the email lists, must be formally submitted and approved. > > > > Formal submission of feature requests will take two forms: 1. > > non-mandatory, but highly recommended is to discuss proposed new features > > on the mailing list. 2. Formal submission of an RFC in a special format. > > I'll give an example of this below, but you can also find it on the web > > site under "Support -> Feature Requests". Since it takes a bit of time > > to properly fill out a RFC form, you probably should check on the email > > list first. > > > > Once I receive the RFC, I will either accept it, send it back asking for > > clarification, send it to the email list asking for opinions, or reject > > it. > > > > If it is accepted, it will go in the "projects" file (a simple ASCII > > file) maintained in the main Bacula source directory. > > > > Implementation of RFCs: > > Any qualified developer can sign up for a project. The project must have > > an entry in the projects file, and the developer's name will appear in > > the Status field. > > > > How RFCs are accepted: > > Acceptance of RFCs depends on several things: 1. feedback from users. If > > it is negative, the RFC will probably not be accepted. 2. the difficulty > > of the project. A project that is so difficult that I cannot imagine > > finding someone to implement probably won't be accepted. 3. whether or > > not the RFC fits within the current stategy of Bacula (for example an RFC > > that requests changing the tape to tar format would not be accepted, ...) > > > > How RFCs are prioritized: > > Once an RFC is accepted, it needs to be implemented. If you can find a > > developer for it, or one signs up for implementing it, then the RFC > > becomes top priority (at least for that developer). > > > > Between releases of Bacula, I will generally solicit RFC input for the > > next version, and by way of this email, I suggest that you send discuss > > and send in your RFCs for the next release. Please verify that the RFC is > > not in the current list (attached to this email). > > > > Once users have had several weeks to submit RFCs, I will organize them, > > and request users to vote on them. This will allow fixing prioritizing > > the RFCs. Having a priority is one thing, but getting it implement is > > another thing -- I am hoping that the Bacula community will take more > > responsibility for assuring the implementation of accepted RFCs. > > > > RFC format: > > ============= Empty RFC form =========== > > Item n: One line summary ... > > Date: Date submitted > > Origin: Name and email of originator. > > Status: > > > > What: More detailed explanation ... > > > > Why: Why it is important ... > > > > Notes: Additional notes or features (omit if not used) > > ============== End RFC form ============== > > > > ============= Example Completed RFC form =========== > > Item 1: Implement a Migration job type that will move the job > > data from one device to another. > > Origin: Sponsored by Riege Sofware International GmbH. Contact: > > Daniel Holtkamp <holtkamp at riege dot com> > > Date: 28 October 2005 > > Status: Partially coded in 1.37 -- much more to do. Assigned to > > Kern. > > > > What: The ability to copy, move, or archive data that is on a > > device to another device is very important. > > > > Why: An ISP might want to backup to disk, but after 30 days > > migrate the data to tape backup and delete it from > > disk. Bacula should be able to handle this > > automatically. It needs to know what was put where, > > and when, and what to migrate -- it is a bit like > > retention periods. Doing so would allow space to be > > freed up for current backups while maintaining older > > data on tape drives. > > > > Notes: Migration could be triggered by: > > Number of Jobs > > Number of Volumes > > Age of Jobs > > Highwater size (keep total size) > > Lowwater mark > > ================================================= > > > > By the end of November, I would like to have all the RFCs for the > > projects file, and have requested users to vote on them. As a > > consequence, please send your RFCs before 21 November, after which we > > will vote and prioritize them ... > > > > This email is already way too long, so I will explain in a subsequent > > email (tomorrow) why I have signed up for project Item 1 -- see the > > attached projects file. > > > > Your comments on this would be welcome -- as well as your RFCs. > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
