git.sur5r.net Git - bacula/docs/blob - docs/home-page/es/pages/feature-request.php

   1 <? require_once("inc/header.php"); ?>
   2 <table>
   3 <tr>
   4    <td class="contentTopic"> Feature Requests </td>
   5 </tr>
   6 <tr>
   7    <td class="content">
   8
   9 <h2>Funded Development</h2>
  10 Now that <a href="http://www.baculasystems.com">Bacula Systems SA</a> exists,
  11 it is possible to sponsor funded development projects. This is a contractual
  12 relationship where the Bacula Systems developers agree to implement
  13 a specific project within a specific time frame. All code that is developed
  14 by Bacula Systems developers, goes into the Bacula community source
  15 repository, so is available for everyone to use.
  16
  17 <h2>Community Development</h2>
  18 If you are not interested in sponsoring a development project, you can
  19 nevertheless submit a feature request to have a favorite feature
  20 implemented (and even submit your own patch for it).
  21
  22 <p>In the past, users informally submitted feature requests by email, and
  23 we collected them, then once a version was released, we would publish the
  24 list for users to vote on.
  25 <p>
  26 Now that Bacula has become a bigger project, this process has been
  27 formalized a bit more. The main change is for users
  28 to carefully think about their feature, and submit it on a feature
  29 request form. A mostly empty form is shown below along with an
  30 example of an actual filled in form. A text copy of the form can
  31 be found in the <b>projects</b> file in the main source directory
  32 of the Bacula release. That file also contains a list of all the
  33 currently approved projects and their status.
  34 <p>
  35 The best time to submit a Feature Request is just after a release when
  36 we officially request feature requests for the next version. The worst
  37 time to submit a feature request is just prior to a new release (we are
  38 very busy at that time).  To actually submit the Feature request,
  39 fill out the form, and submit it to both the bacula-users and
  40 the bacula-devel email lists. It will then be openly discussed.
  41 <p>
  42 Once the Feature Request has beeen adequately discussed, Bacula Project
  43 Manager (Kern) will either reject it, approve it, or possibly request some
  44 modifications.  If you plan to implement the feature or donate
  45 funds to have it implemented, this is important to note,
  46 otherwise, the feature, even if approved, may wait a long time
  47 for someone to implement it.
  48 <p>
  49 Once the Feature request is approved, we will add it to the projects
  50 file, which contains a list of all open Feature Requests.  The projects
  51 file is updated from time to time
  52 <p>
  53 The current (though possibly somewhat old) list of projects can also
  54 be found on the Web site by clicking on the Projects menu item to the
  55 left of this window.
  56
  57
  58 <h3>Feature Request Form</h3>
  59 <pre>
  60 Item n:   One line summary ...
  61   Origin: Name and email of originator.
  62   Date:   Date submitted (e.g. 28 October 2005)
  63   Status:
  64
  65   What:   More detailed explanation ...
  66
  67   Why:    Why it is important ...
  68
  69   Notes:  Additional notes or features ...
  70
  71 </pre>
  72
  73 <h3>An Example Feature Request</h3>
  74 <pre>
  75 Item 1:   Implement a Migration job type that will move the job
  76           data from one device to another.
  77   Date:   28 October 2005
  78   Origin: Sponsored by Riege Sofware International GmbH. Contact:
  79           Daniel Holtkamp <holtkamp at riege dot com>
  80   Status: Partially coded in 1.37 -- much more to do. Assigned to
  81           Kern.
  82
  83   What:   The ability to copy, move, or archive data that is on a
  84           device to another device is very important.
  85
  86   Why:    An ISP might want to backup to disk, but after 30 days
  87           migrate the data to tape backup and delete it from
  88           disk.  Bacula should be able to handle this
  89           automatically.  It needs to know what was put where,
  90           and when, and what to migrate -- it is a bit like
  91           retention periods.  Doing so would allow space to be
  92           freed up for current backups while maintaining older
  93           data on tape drives.
  94
  95   Notes:  Migration could be triggered by:
  96            Number of Jobs
  97            Number of Volumes
  98            Age of Jobs
  99            Highwater size (keep total size)
 100            Lowwater mark
 101
 102 </pre>
 103
 104 </td>
 105 </tr>
 106
 107 </table>
 108 <? require_once("inc/footer.php"); ?>