Sophie

Sophie

distrib > Fedora > 16 > i386 > by-pkgid > df754e4e6f7f5fc8ab9d6ed8559f3e3d > files > 51

bacula-docs-5.0.3-19.fc16.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<!--Converted with LaTeX2HTML 2008 (1.71)
original version by:  Nikos Drakos, CBLU, University of Leeds
* revised and updated by:  Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
  Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>The Development Cycle</TITLE>
<META NAME="description" CONTENT="The Development Cycle">
<META NAME="keywords" CONTENT="developers">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">

<META NAME="Generator" CONTENT="LaTeX2HTML v2008">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

<LINK REL="STYLESHEET" HREF="developers.css">

<LINK REL="next" HREF="Bacula_Code_Submissions_Pro.html">
<LINK REL="previous" HREF="Bacula_Developer_Notes.html">
<LINK REL="up" HREF="Bacula_Developer_Notes.html">
<LINK REL="next" HREF="Bacula_Code_Submissions_Pro.html">
</HEAD>

<BODY >
<!--Navigation Panel-->
<A NAME="tex2html465"
  HREF="Bacula_Code_Submissions_Pro.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<A NAME="tex2html459"
  HREF="Bacula_Developer_Notes.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> 
<A NAME="tex2html453"
  HREF="Bacula_Developer_Notes.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> 
<A NAME="tex2html461"
  HREF="Contents.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A> 
<A NAME="tex2html463"
  HREF="GNU_Free_Documentation_Lice.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html466"
  HREF="Bacula_Code_Submissions_Pro.html">Bacula Code Submissions and</A>
<B> Up:</B> <A NAME="tex2html460"
  HREF="Bacula_Developer_Notes.html">Bacula Developer Notes</A>
<B> Previous:</B> <A NAME="tex2html454"
  HREF="Bacula_Developer_Notes.html">Bacula Developer Notes</A>
 &nbsp; <B>  <A NAME="tex2html462"
  HREF="Contents.html">Contents</A></B> 
 &nbsp; <B>  <A NAME="tex2html464"
  HREF="GNU_Free_Documentation_Lice.html">Index</A></B> 
<BR>
<BR>
<!--End of Navigation Panel-->

<H1><A NAME="SECTION00210000000000000000"></A>
<A NAME="141"></A>
<A NAME="142"></A>
<BR>
The Development Cycle
</H1>

<P>
As discussed on the email lists, the number of contributions are
increasing significantly.  We expect this positive trend
will continue.  As a consequence, we have modified how we do
development, and instead of making a list of all the features that we will
implement in the next version, each developer signs up for one (maybe
two) projects at a time, and when they are complete, and the code
is stable, we will release a new version.  The release cycle will probably
be roughly six months.

<P>
The difference is that with a shorter release cycle and fewer released
feature, we 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 (some prior versions had too many new features for us to handle
correctly).

<P>
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 :-)

<P>
<A NAME="146"></A>
<B>Feature Requests:</B> 
<BR>
In addition, we have "formalizee" the feature requests a bit.

<P>
Instead of me maintaining an informal list of everything I run into 
(kernstodo), we now 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. 

<P>
Formal submission of feature requests will take two forms: 
<BR>
1. non-mandatory, but highly recommended is to discuss proposed new features
on the mailing list.
<BR>
2.  Formal submission of an Feature Request in a special format.  We'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 Feature Request form, you probably should check on the
email list first.

<P>
Once the Feature Request is received by the keeper of the projects list, it
will be sent to the Bacula project manager (Kern), and he will either
accept it (90the time), send it to the email list asking for opinions, or reject it
(very few cases).

<P>
If it is accepted, it will go in the "projects" file (a simple ASCII file) 
maintained in the main Bacula source directory.

<P>
<B>Implementation of Feature Requests:</B>
<BR>
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.

<P>
<B>How Feature Requests are accepted:</B>
<BR>
Acceptance of Feature Requests depends on several things: 
<BR>
1.  feedback from users.  If it is negative, the Feature Request will probably not be
accepted.  
<BR>
2.  the difficulty of the project.  A project that is so
difficult that we cannot imagine finding someone to implement probably won't
be accepted. Obviously if you know how to implement it, don't hesitate
to put it in your Feature Request  
<BR>
3.  whether or not the Feature Request fits within the current strategy of
Bacula (for example an Feature Request that requests changing the tape to
tar format probably would not be accepted, ...).

<P>
<B>How Feature Requests are prioritized:</B>
<BR>
Once an Feature Request is accepted, it needs to be implemented.  If you
can find a developer for it, or one signs up for implementing it, then the
Feature Request becomes top priority (at least for that developer).

<P>
Between releases of Bacula, we will generally solicit Feature Request input
for the next version, and by way of this email, we suggest that you send
discuss and send in your Feature Requests for the next release.  Please
verify that the Feature Request is not in the current list (attached to this email).

<P>
Once users have had several weeks to submit Feature Requests, the keeper of
the projects list will organize them, and request users to vote on them.
This will allow fixing prioritizing the Feature Requests.  Having a
priority is one thing, but getting it implement is another thing - we are
hoping that the Bacula community will take more responsibility for assuring
the implementation of accepted Feature Requests.

<P>
Feature Request format:
<PRE>
============= Empty Feature Request 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 Feature Request form ==============
</PRE>

<P>
<PRE>
============= Example Completed  Feature Request 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 &lt;holtkamp at riege dot com&gt;
  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
=================================================
</PRE>

<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html465"
  HREF="Bacula_Code_Submissions_Pro.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<A NAME="tex2html459"
  HREF="Bacula_Developer_Notes.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> 
<A NAME="tex2html453"
  HREF="Bacula_Developer_Notes.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> 
<A NAME="tex2html461"
  HREF="Contents.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A> 
<A NAME="tex2html463"
  HREF="GNU_Free_Documentation_Lice.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A> 
<BR>
<B> Next:</B> <A NAME="tex2html466"
  HREF="Bacula_Code_Submissions_Pro.html">Bacula Code Submissions and</A>
<B> Up:</B> <A NAME="tex2html460"
  HREF="Bacula_Developer_Notes.html">Bacula Developer Notes</A>
<B> Previous:</B> <A NAME="tex2html454"
  HREF="Bacula_Developer_Notes.html">Bacula Developer Notes</A>
 &nbsp; <B>  <A NAME="tex2html462"
  HREF="Contents.html">Contents</A></B> 
 &nbsp; <B>  <A NAME="tex2html464"
  HREF="GNU_Free_Documentation_Lice.html">Index</A></B> 
<!--End of Navigation Panel-->
<ADDRESS>

2012-01-24
</ADDRESS>
</BODY>
</HTML>