940 lines
28 KiB
HTML
940 lines
28 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Maintaining a Project: Interacting with Developers</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
|
|
"><LINK
|
|
REL="HOME"
|
|
TITLE="Free Software Project Management HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Starting a Project"
|
|
HREF="starting.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Maintaining a Project: Interacting with Users"
|
|
HREF="users.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Free Software Project Management HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="starting.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="users.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="DEVELOPERS">3. Maintaining a Project: Interacting with Developers</H1
|
|
><P
|
|
> Once you have gotten your project started, you have overcome the
|
|
most difficult hurdles in the development process of your
|
|
program. Laying a firm foundation is essential, but the development
|
|
process itself is equally important and provides just as many
|
|
opportunities for failure. In the next two sections, I will
|
|
describe running a project by discussing how to maintain a
|
|
development effort through interactions with developers and with
|
|
users.
|
|
</P
|
|
><P
|
|
> In releasing your program, your program becomes free software. This
|
|
transition is more than just a larger user base. By releasing your
|
|
program as free software, <EM
|
|
>your</EM
|
|
> software
|
|
becomes the <EM
|
|
>free software community's</EM
|
|
>
|
|
software. The direction of your software's development will be
|
|
reshaped, redirected, and fully determined by your users and, to a
|
|
larger extent, by other developers in the community.
|
|
</P
|
|
><P
|
|
> The major difference between free software development and
|
|
propriety software development is the developer base. As the leader
|
|
of a free software project, you need to attract and keep developers
|
|
in a way that leaders of proprietary software projects simply don't
|
|
have to worry about. <EM
|
|
>As the person leading development of
|
|
a free software project, you must harness the work of fellow
|
|
developers by making responsible decisions and by responsibly
|
|
choosing not to make decisions. You have to direct developers
|
|
without being overbearing or bossy. You need to strive to earn
|
|
respect and never forget to give it out.</EM
|
|
>
|
|
</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="DELEGATION">3.1. Delegating Work</H2
|
|
><P
|
|
> By now, you've hypothetically followed me through the early
|
|
programming of a piece of software, the creation of a website and
|
|
system of documentation, and we've gone ahead and (as will be
|
|
discussed in <A
|
|
HREF="users.html#RELEASING"
|
|
>Section 4.3</A
|
|
>) released it to the rest
|
|
of the world. Times passes, and if things go well, people become
|
|
interested and want to help. The patches begin flowing in.
|
|
</P
|
|
><P
|
|
> <EM
|
|
>Like the parent of any child who grows up, it's now time
|
|
to wince, smile and do most difficult thing in any parents
|
|
life: It's time to let go.</EM
|
|
>
|
|
</P
|
|
><P
|
|
> Delegation is the political way of describing this process of
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"letting go."</SPAN
|
|
> It is the process of handing some of
|
|
the responsibility and power over your project to other
|
|
responsible and involved developers. It is difficult for anyone
|
|
who has invested a large deal of time and energy into a project
|
|
but it essential for the growth of any free software project. One
|
|
person can only do so much. A free software project is nothing
|
|
without the involvement of <EM
|
|
>a group</EM
|
|
> of
|
|
developers. A group of developers can only be maintained through
|
|
respectful and responsible leadership and delegation.
|
|
</P
|
|
><P
|
|
> As your project progresses, you will notice people who are putting
|
|
significant amounts of time and effort into your project. These
|
|
will be the people submitting the most patches, posting most on
|
|
the mailing lists, and engaging in long email discussions. It is
|
|
your responsibility to contact these people and to try and shift
|
|
some of the power and responsibility of your position as the
|
|
project's maintainer onto them (if they want it). There are
|
|
several easy ways you can do this:
|
|
</P
|
|
><P
|
|
> In a bit of a disclaimer, delegation need not mean rule by
|
|
committee. In many cases it does and this has been proven to
|
|
work. In other cases this has created problems. <A
|
|
HREF="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD"
|
|
TARGET="_top"
|
|
>Managing
|
|
Projects the Open Source Way</A
|
|
> argues that <SPAN
|
|
CLASS="QUOTE"
|
|
>"OSS
|
|
projects do best when one person is the clear leader of a team and
|
|
makes the big decisions (design changes, release dates, and so
|
|
on)."</SPAN
|
|
> I think this often true but would urge developers to
|
|
consider the ideas that the project leader need not be the
|
|
project's founder and that these important powers need not all rest
|
|
with one person but that a release manager may be different than a
|
|
lead developer. These situations are tricky politically so
|
|
be careful and make sure it's necessary before you go around
|
|
empowering people.
|
|
</P
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN470">3.1.1. How to delegate</H3
|
|
><P
|
|
> You may find that other developers seem even more experienced or
|
|
knowledgeable than you. Your job as a maintainer does not mean
|
|
you have to be the best or the brightest. It means you
|
|
are responsible for showing good judgment and for
|
|
recognizing which solutions are maintainable and which are not.
|
|
</P
|
|
><P
|
|
> Like anything, its easier to watch others delegate than to do it
|
|
yourself. In a sentence: <EM
|
|
>Keep an eye out for other
|
|
qualified developers who show an interest and sustained
|
|
involvement with your project and try and shift responsibility
|
|
toward them.</EM
|
|
> The following ideas might be good places
|
|
to start or good sources of inspiration:
|
|
</P
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN475">3.1.1.1. Allow a larger group of people to have write access to your CVS
|
|
repository and make real efforts toward rule by a
|
|
committee</H4
|
|
><P
|
|
> <A
|
|
HREF="http://httpd.apache.org/"
|
|
TARGET="_top"
|
|
>Apache</A
|
|
> is an
|
|
example of a project that is run by small group of developers
|
|
who vote on major technical issues and the admission of new
|
|
members and all have write access to the main source
|
|
repository. Their process is detailed <A
|
|
HREF="http://httpd.apache.org/ABOUT_APACHE.html"
|
|
TARGET="_top"
|
|
>online.</A
|
|
>
|
|
</P
|
|
><P
|
|
> The <A
|
|
HREF="http://www.debian.org/"
|
|
TARGET="_top"
|
|
> Debian Project</A
|
|
>
|
|
is an extreme example of rule by committee. At current count,
|
|
more than 700 developers have full responsibility for
|
|
aspects of the project. All these developers can upload into
|
|
the main FTP server, and vote on major issues. Direction for
|
|
the project is determined by the project's <A
|
|
HREF="http://www.debian.org/social_contract"
|
|
TARGET="_top"
|
|
>social
|
|
contract</A
|
|
> and a <A
|
|
HREF="http://www.debian.org/devel/constitution"
|
|
TARGET="_top"
|
|
>constitution</A
|
|
>. To
|
|
facilitate this system, there are special teams (i.e. the
|
|
install team, the Japanese language team) as well as a technical
|
|
committee and a project leader. The leader's main responsibility
|
|
is to, <SPAN
|
|
CLASS="QUOTE"
|
|
>"appoint delegates or delegate decisions to the
|
|
Technical Committee."</SPAN
|
|
>
|
|
</P
|
|
><P
|
|
> While both of these projects operate on a scale that your
|
|
project will not (at least initially), their example is
|
|
helpful. Debian's idea of a project leader who can do
|
|
<EM
|
|
>nothing</EM
|
|
> but delegate serves as a
|
|
caricature of how a project can involve and empower a huge
|
|
number of developers and grow to a huge size.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="RELEASEMANAGER">3.1.1.2. Publicly appoint someone as the release manager for a
|
|
specific release</H4
|
|
><P
|
|
> A release manager is usually responsible for coordinating
|
|
testing, enforcing a code freeze, being responsible for
|
|
stability and quality control, packaging up the software, and
|
|
placing it in the appropriate places to be downloaded.
|
|
</P
|
|
><P
|
|
> This use of the release manager is a good way to give yourself a
|
|
break and to shift the responsibility for accepting and
|
|
rejecting patches onto someone else. It is a good way of very
|
|
clearly defining a chunk of work on the project as belonging to
|
|
a certain person and its a great way of giving yourself room to
|
|
breath.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="DELEGATEBRANCH">3.1.1.3. Delegate control of an entire branch</H4
|
|
><P
|
|
> If your project chooses to have branches (as described in <A
|
|
HREF="developers.html#BRANCHES"
|
|
>Section 3.3</A
|
|
>), it might be a good idea to appoint someone
|
|
else to be the the head of a branch. If you like focusing your
|
|
energy on development releases and the implementation of new
|
|
features, hand total control over the stable releases to a
|
|
well-suited developer.
|
|
</P
|
|
><P
|
|
> The author of Linux, Linus Torvalds, came out and crowned Alan
|
|
Cox as <SPAN
|
|
CLASS="QUOTE"
|
|
>"the man for stable kernels."</SPAN
|
|
> All patches
|
|
for stable kernels go to Alan and, if Linus were to be taken
|
|
away from work on Linux for any reason, Alan Cox would be more
|
|
than suited to fill his role as the acknowledged heir to the
|
|
Linux maintainership.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="PATCHING">3.2. Accepting and Rejecting Patches</H2
|
|
><P
|
|
> This HOWTO has already touched on the fact that as the maintainer
|
|
of a free software project, one of your primary and most important
|
|
responsibilities will be accepting and rejecting patches submitted
|
|
to you by other developers.
|
|
</P
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN500">3.2.1. Encouraging Good Patching</H3
|
|
><P
|
|
>As the person managing or maintaining the project, you
|
|
aren't the person who is going to be making a lot of
|
|
patches. However, it's worth knowing about ESR's section on
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>Good Patching Practice</I
|
|
> in the
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>Software Release Practices HOWTO</I
|
|
><A
|
|
HREF="b811.html#ESRHOWTO"
|
|
>[ESRHOWTO]</A
|
|
>. I don't agree with ESR's claim that most ugly
|
|
or undocumented patches are probably worth throwing out at first
|
|
sight--this just hasn't been my experience, especially when
|
|
dealing with bug fixes that often don't come in the form of
|
|
patches at all. Of course, this doesn't mean that I
|
|
<EM
|
|
>like</EM
|
|
> getting poorly done patches. If you get
|
|
ugly -e patches, if you get totally undocumented patches, and
|
|
especially if they are anything more than trivial bug-fixes, it
|
|
might be worth judging the patch by some of the criteria in ESR's
|
|
HOWTO and then throwing people the link to the document so they
|
|
can do it the <SPAN
|
|
CLASS="QUOTE"
|
|
>"right way."</SPAN
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN508">3.2.2. Technical judgment</H3
|
|
><P
|
|
> In <EM
|
|
>Open Source Development with CVS</EM
|
|
>, Karl
|
|
Fogel makes a convincing argument that the most important things
|
|
to keep in mind when rejecting or accepting patches are:
|
|
</P
|
|
><P
|
|
> <P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>A firm knowledge of the scope of your program (that's the
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"idea"</SPAN
|
|
> I talked about in <A
|
|
HREF="starting.html#CHOOSEPROJECT"
|
|
>Section 2.1</A
|
|
>);</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The ability to recognize, facilitate, and direct
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"evolution"</SPAN
|
|
> of your program so that the program
|
|
can grow and change and incorporate functionality that was
|
|
originally unforeseen;</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The necessity to avoid digressions that might expand the
|
|
scope of the program too much and result and push the project
|
|
toward an early death under its own weight and
|
|
unwieldiness.</P
|
|
></LI
|
|
></UL
|
|
>
|
|
</P
|
|
><P
|
|
> These are the criteria that you as a project maintainer should
|
|
take into account each time you receive a patch.
|
|
</P
|
|
><P
|
|
> Fogel elaborates on this and states the <SPAN
|
|
CLASS="QUOTE"
|
|
>"the
|
|
questions to ask yourself when considering whether to implement
|
|
(or approve) a change are:"</SPAN
|
|
>
|
|
</P
|
|
><P
|
|
> <P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Will it benefit a significant percentage of the program's
|
|
user community?</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Does it fit within the program's domain or within a
|
|
natural, intuitive extension of that domain?</P
|
|
></LI
|
|
></UL
|
|
>
|
|
</P
|
|
><P
|
|
> The answers to these questions are never straightforward and its
|
|
very possible (and even likely) that the person who submitted the
|
|
patch may feel differently about the answer to these questions
|
|
than you do. However, if you feel that that the answer to either
|
|
of those questions is <SPAN
|
|
CLASS="QUOTE"
|
|
>"no,"</SPAN
|
|
> it is your responsibility
|
|
to reject the change. If you fail to do this, the project will
|
|
become unwieldy and unmaintainable and many ultimately fail.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="AEN534">3.2.3. Rejecting patches</H3
|
|
><P
|
|
> Rejecting patches is probably the most difficult and sensitive
|
|
job that the maintainer of any free software project has to
|
|
face. But sometimes it has to be done. I mentioned earlier (in
|
|
<A
|
|
HREF="developers.html"
|
|
>Section 3</A
|
|
> and in <A
|
|
HREF="developers.html#DELEGATION"
|
|
>Section 3.1</A
|
|
>)
|
|
that you need to try and balance your responsibility and power to
|
|
make what you think are the best technical decisions with the
|
|
fact that you will lose support from other developers if you seem
|
|
like you are on a power trip or being overly bossy or possessive
|
|
of the community's project. I recommend that you keep these three
|
|
major concepts in mind when rejecting patches (or other changes):
|
|
</P
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN539">3.2.3.1. Bring it to the community</H4
|
|
><P
|
|
> One of the best ways of justifying a decision to reject a patch
|
|
and working to not seem like you keep an iron grip on your
|
|
project is by not making the decision alone at all. It might
|
|
make sense to turn over larger proposed changes or more
|
|
difficult decisions to a development mailing list where they can
|
|
be discussed and debated. There will be some patches (bug fixes,
|
|
etc.) which will definitely be accepted and some that you feel
|
|
are so off base that they do not even merit further
|
|
discussion. It is those that fall into the gray area between
|
|
these two groups that might merit a quick forward to a mailing
|
|
list.
|
|
</P
|
|
><P
|
|
> I recommend this process wholeheartedly. As the project
|
|
maintainer you are worried about making the best decision for
|
|
the project, for the project's users and developers, and for
|
|
yourself as a responsible project leader. Turning things over to
|
|
an email list will demonstrate your own responsibility and
|
|
responsive leadership as it tests and serves the interests of
|
|
your software's community.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN543">3.2.3.2. Technical issues are not always good justification</H4
|
|
><P
|
|
> Especially toward the beginning of your project's life, you
|
|
will find that many changes are difficult to implement,
|
|
introduce new bugs, or have other technical problems. Try to see
|
|
past these. Especially with added functionality, good ideas do
|
|
not always come from good programmers. Technical merit is a
|
|
valid reason to postpone an application of a patch but it is not
|
|
always a good reason to reject a change outright. Even small
|
|
changes are worth the effort of working with the developer
|
|
submitting the patch to iron out bugs and incorporate the change
|
|
if you think it seems like a good addition to your project. The
|
|
effort on your part will work to make your project a community
|
|
project and it will pull a new or less experienced developer
|
|
into your project and even teach them something that might help
|
|
them in making their next patch.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT4"
|
|
><H4
|
|
CLASS="SECT4"
|
|
><A
|
|
NAME="AEN546">3.2.3.3. Common courtesy</H4
|
|
><P
|
|
> It should go without saying but, <EM
|
|
>above all and in all
|
|
cases, just be nice.</EM
|
|
> If someone has an idea and cares
|
|
about it enough to write some code and submit a patch, they
|
|
care, they are motivated, and they are already involved. Your
|
|
goal as the maintainer is make sure they submit again. They may
|
|
have thrown you a dud this time but next time may be the idea or
|
|
feature that revolutionizes your project.
|
|
</P
|
|
><P
|
|
> It is your responsibility to first justify your choice to not
|
|
incorporate their change clearly and concisely. Then thank
|
|
them. Let them know that you a appreciate their help and feel
|
|
horrible that you can't incorporate their change. Let them know
|
|
that you look forward to their staying involved and you hope
|
|
that the next patch or idea meshes better with your project
|
|
because you appreciate their work and want to see it in your
|
|
application. If you have ever had a patch rejected after putting
|
|
a large deal of time, thought, and energy into it, you remember
|
|
how it feels and it feels bad. Keep this in mind when you have
|
|
to let someone down. It's never easy but you need to do
|
|
everything you can to make it as not-unpleasant as possible.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="BRANCHES">3.3. Stable and Development Branches</H2
|
|
><P
|
|
> The idea of stable and development branches has already been
|
|
described briefly in <A
|
|
HREF="starting.html#CHOOSEVERSIONING"
|
|
>Section 2.4</A
|
|
> and in
|
|
<A
|
|
HREF="developers.html#DELEGATEBRANCH"
|
|
>Section 3.1.1.3</A
|
|
>. These allusions attest to some of
|
|
the ways that multiple branches can affect your software. Branches
|
|
can let you avoid (to some extent) some of the problems around
|
|
rejecting patches (as described in <A
|
|
HREF="developers.html#PATCHING"
|
|
>Section 3.2</A
|
|
>) by
|
|
allowing you to temporarily compromise the stability of your
|
|
project without affecting those users who need that stability.
|
|
</P
|
|
><P
|
|
> The most common way of branching your project is to have one
|
|
branch that is stable and one that is for development. This is the
|
|
model followed by the Linux kernel that is described in <A
|
|
HREF="starting.html#CHOOSEVERSIONING"
|
|
>Section 2.4</A
|
|
>. In this model, there is
|
|
<EM
|
|
>always</EM
|
|
> one branch that is stable and always
|
|
one that is in development. Before any new release, the
|
|
development branch goes into a <SPAN
|
|
CLASS="QUOTE"
|
|
>"feature freeze"</SPAN
|
|
> as
|
|
described in <A
|
|
HREF="developers.html#FREEZING"
|
|
>Section 3.4.1</A
|
|
> where major changes and
|
|
added features are rejected or put on hold under the development
|
|
kernel is released as the new stable branch and major development
|
|
resumes on the development branch. Bug fixes and small changes
|
|
that are unlikely to have any large negative repercussions are
|
|
incorporated into the stable branch as well as the development
|
|
branch.
|
|
</P
|
|
><P
|
|
> Linux's model provides an extreme example. On many projects, there is no
|
|
need to have two versions constantly available. It may make sense to
|
|
have two versions only near a release. The Debian project has
|
|
historically made both a stable and an unstable distribution
|
|
available but has expanded to this to include: stable, unstable,
|
|
testing, experimental, and (around release time) a frozen
|
|
distribution that only incorporates bug fixes during the
|
|
transition from unstable to stable. There are few projects whose
|
|
size would necessitate a system like Debian's but this use of
|
|
branches helps demonstrate how they can be used to balance
|
|
consistent and effective development with the need to make regular
|
|
and usable releases.
|
|
</P
|
|
><P
|
|
> In trying to set up a development tree for yourself, there are
|
|
several things that might be useful to keep in mind:
|
|
</P
|
|
><P
|
|
> <P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>Minimize the number of branches</DT
|
|
><DD
|
|
><P
|
|
>Debian may be able to make good use of four or five
|
|
branches but it contains gigabytes of software in over 5000
|
|
packages compiled for 5-6 different architectures. For you,
|
|
two is probably a good ceiling. Too many branches will confuse
|
|
your users (I can't count how many times I had to describe
|
|
Debian's system when it only had 2 and sometimes 3 branches!),
|
|
potential developers and even yourself. Branches can help but
|
|
they come at a cost so use them very sparingly.</P
|
|
></DD
|
|
><DT
|
|
>Make sure that all your different branches are explained</DT
|
|
><DD
|
|
><P
|
|
>As I mentioned in the preceding paragraph, different
|
|
branches <EM
|
|
>will</EM
|
|
> confuse your users. Do
|
|
everything you can to avoid this by clearly explaining the
|
|
different branches in a prominent page on your website and in a
|
|
README file in the <SPAN
|
|
CLASS="ACRONYM"
|
|
>FTP</SPAN
|
|
> or
|
|
web directory.</P
|
|
><P
|
|
> I might also recommend against a mistake that I think Debian
|
|
has made. The terms <SPAN
|
|
CLASS="QUOTE"
|
|
>"unstable,"</SPAN
|
|
>
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"testing,"</SPAN
|
|
> and <SPAN
|
|
CLASS="QUOTE"
|
|
>"experimental"</SPAN
|
|
> are
|
|
vague and difficult to rank in order of stability (or
|
|
instability as the case may be). Try explaining to someone
|
|
that <SPAN
|
|
CLASS="QUOTE"
|
|
>"stable"</SPAN
|
|
> actually means <SPAN
|
|
CLASS="QUOTE"
|
|
>"ultra
|
|
stable"</SPAN
|
|
> and that <SPAN
|
|
CLASS="QUOTE"
|
|
>"unstable"</SPAN
|
|
> doesn't
|
|
actually include any unstable software but is really stable
|
|
software that is untested as a distribution.
|
|
</P
|
|
><P
|
|
> If you are going to use branches, especially early on, keep in
|
|
mind that people are conditioned to understand the terms
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"stable"</SPAN
|
|
> and <SPAN
|
|
CLASS="QUOTE"
|
|
>"development"</SPAN
|
|
> and you
|
|
probably can't go wrong with this simple and common division of
|
|
branches.
|
|
</P
|
|
></DD
|
|
><DT
|
|
>Make sure all your branches are always available</DT
|
|
><DD
|
|
><P
|
|
>Like a lot of this document, this should probably should
|
|
go without saying but experience has taught me that it's not
|
|
always obvious to people. It's a good idea to physically split
|
|
up different branches into different directories or directory
|
|
trees on your <SPAN
|
|
CLASS="ACRONYM"
|
|
>FTP</SPAN
|
|
> or web site. Linux
|
|
accomplishes this by having kernels in a v2.2 and a v2.3
|
|
subdirectory where it is immediately obvious (after you know
|
|
their version numbering scheme) which directory is for the most
|
|
recent stable and the current development releases. Debian
|
|
accomplishes this by naming all their distribution with names
|
|
(i.e. woody, potato, etc.) and then changing symlinks named
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"stable,"</SPAN
|
|
> <SPAN
|
|
CLASS="QUOTE"
|
|
>"unstable"</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"frozen"</SPAN
|
|
> to point to which ever distribution (by
|
|
name) is in whatever stage. Both methods work and there are
|
|
others. In any case, it is important that different branches
|
|
are always available, are accessible from consistent locations,
|
|
and that different branches are clearly distinguished from each
|
|
other so your users know exactly what they want and where to
|
|
get it.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
>
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="OTHERDEV">3.4. Other Project Management issues</H2
|
|
><P
|
|
> There are more issues surrounding interaction with developers in a
|
|
free software project that I can not touch on in great detail in a
|
|
HOWTO of this size and scope. Please don't hesitate to contact me if you see
|
|
any major omissions.
|
|
</P
|
|
><P
|
|
> Other smaller issues that are worth mentioning are:
|
|
</P
|
|
><DIV
|
|
CLASS="SECT3"
|
|
><H3
|
|
CLASS="SECT3"
|
|
><A
|
|
NAME="FREEZING">3.4.1. Freezing</H3
|
|
><P
|
|
> For those projects that choose to adopt a split development model
|
|
(<A
|
|
HREF="developers.html#BRANCHES"
|
|
>Section 3.3</A
|
|
>), freezing is a concept that is worth
|
|
becoming familiar with.
|
|
</P
|
|
><P
|
|
> Freezes come in two major forms. A <SPAN
|
|
CLASS="QUOTE"
|
|
>"feature freeze"</SPAN
|
|
>
|
|
is a period when no significant functionality is added to a
|
|
program. It is a period where established functionality (even
|
|
skeletons of barely working functionality) can be improved and
|
|
perfected. It is a period where bugs are fixed. This type of
|
|
freeze is usually applied some period (a month or two) before a
|
|
release. It is easy to push a release back as you wait for
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"one more feature"</SPAN
|
|
> and a freeze helps to avoid this
|
|
situation by drawing the much needed line in the sand. It gives
|
|
developers room they need to get a program ready for release.
|
|
</P
|
|
><P
|
|
> The second type of freeze is a <SPAN
|
|
CLASS="QUOTE"
|
|
>"code freeze"</SPAN
|
|
> which
|
|
is much more like a released piece of software. Once a piece of
|
|
software has entered a <SPAN
|
|
CLASS="QUOTE"
|
|
>"code freeze,"</SPAN
|
|
> all changes to
|
|
the code are discouraged and only changes that fix known bugs
|
|
are permitted. This type of freeze usually follows a
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"feature freeze"</SPAN
|
|
> and directly precedes a
|
|
release. Most released software is in what could be interpreted
|
|
as a sort of high level <SPAN
|
|
CLASS="QUOTE"
|
|
>"code freeze."</SPAN
|
|
>
|
|
</P
|
|
><P
|
|
> Even if you never choose to appoint a release manager (<A
|
|
HREF="developers.html#RELEASEMANAGER"
|
|
>Section 3.1.1.2</A
|
|
>), you will have an easier time
|
|
justifying the rejection or postponement of patches (<A
|
|
HREF="developers.html#PATCHING"
|
|
>Section 3.2</A
|
|
>) before a release with a publicly stated
|
|
freeze in effect.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN613">3.5. Forks</H2
|
|
><P
|
|
> I wasn't sure about how I would deal with forking in this
|
|
document (or if I would deal with forking at all). A fork is when
|
|
a group of developers takes code from a free software project and
|
|
actually starts a brand new free software project with it. The
|
|
most famous example of a fork was between Emacs and XEmacs. Both
|
|
emacsen are based on an identical code-base but for technical,
|
|
political, and philosophical reasons, development was split into
|
|
two projects which now compete with each other.
|
|
</P
|
|
><P
|
|
> The short version of the fork section is, <EM
|
|
>don't do
|
|
them.</EM
|
|
> Forks force developers to choose one project to
|
|
work with, cause nasty political divisions, and redundancy of
|
|
work. Luckily, usually the threat of the fork is enough to scare
|
|
the maintainer or maintainers of a project into changing the way
|
|
they run their project.
|
|
</P
|
|
><P
|
|
> In his chapter on <SPAN
|
|
CLASS="QUOTE"
|
|
>"The Open Source Process,"</SPAN
|
|
> Karl
|
|
Fogel describes how to do a fork if you absolutely must. If you
|
|
have determined that is absolutely necessary and that the
|
|
differences between you and the people threatening to fork are
|
|
absolutely unresolvable, I recommend Fogel's book as a good place
|
|
to start.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="starting.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="users.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Starting a Project</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Maintaining a Project: Interacting with Users</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |