[med-svn] r5586 - trunk/community/papers/11_med-floss_luxemburg
Yaroslav Halchenko
yoh at alioth.debian.org
Fri Dec 10 05:59:21 UTC 2010
Author: yoh
Date: 2010-12-10 05:59:20 +0000 (Fri, 10 Dec 2010)
New Revision: 5586
Modified:
trunk/community/papers/11_med-floss_luxemburg/paper-text.tex
Log:
worked on the growth part a little -- it has grown ;)
Modified: trunk/community/papers/11_med-floss_luxemburg/paper-text.tex
===================================================================
--- trunk/community/papers/11_med-floss_luxemburg/paper-text.tex 2010-12-10 04:39:12 UTC (rev 5585)
+++ trunk/community/papers/11_med-floss_luxemburg/paper-text.tex 2010-12-10 05:59:20 UTC (rev 5586)
@@ -574,21 +574,21 @@
\subsubsection{Metapackages}
-Debian offers many tens of thousands of packages. It is considered
+Debian offers tens of thousands of software, data and documentation packages. It is considered
helpful for the users (who might not have the right to install
packages himself) to specify all biomedical software with
-one single instruction -- to the local shell or to the local system
+single instruction given to the local shell or to the local system
administrator.
\DebianMed contains a set of metapackages that
declare dependencies on other Debian package to thus prepare
the system for solving particular tasks. The user
-then only seeks for metapackages starting with prefix \package{med-}
-and installs the metapackage of choice.
-The package management system will care for
+then needs to seek only for metapackages starting with prefix \package{med-}
+to install just few of them to fulfill his software selection requirements.
+The package management system then will take care about
the installation of all packages that are in the list of dependencies
-of this metapackage -- so the user can be sure that all packages he
-might need for the job will be installed on his system. Once one of
+of these metapackages -- so the user can be sure that all packages he
+might need for the job will be installed on his system. Once any of
the metapackages is installed, a special user menu will be created to
enhance usability for the user working in the field of medicine.
@@ -605,10 +605,10 @@
have to install only one single package using a package management
software inside Debian to get all interesting packages which are
necessary for a single task. For
-instance if a user types in: \\
+instance a single command \\
\hspace*{10mm}\texttt{apt-get install med-bio} \\
-all applications inside Debian which are related to the field of
-molecular biology and medical genetics will be installed.
+results in installation of all applications inside Debian which are related to the field of
+molecular biology and medical genetics.
\subsubsection{Continuous growth}
@@ -620,15 +620,26 @@
\label{figure:dmstats}
\end{figure}
-Once a software was packaged, the effort for future maintenance is
-comparatively small. But one needs to be careful not to lose one's
-energy to investigate on bug reports and to follow the "upstream"
+Once a software is packaged, the effort for future maintenance is
+relatively small. Nevertheless, care is needed not to exhaust initial maintainer's
+enthusiasm since continuous maintenance requires investigation of submitted bug reports and following the "upstream"
development. Also, for many package maintainers, to understand
-the code of upstream, to learn from and to contribute to it is part
-of their motivation - and that does not scale. In the longer run,
-continuous growth can only come through additional contributors
-the the distribution. And with the Debian Maintainers program \marginpar{please add a ref},
-for anyone interested this is only a couple of emails away.
+the upstream code, to learn from it and to contribute back is a part
+of their motivation - and that often does not scale. In the longer run,
+continuous growth can only come through attracting additional contributors
+to the Debian project. Debian welcome contributions and setup
+\printurl{wiki.debian.org/SponsoredMaintainer}{Sponsored Maintainer} and
+\printurl{wiki.debian.org/DebianMaintainer}{Debian Maintainer} programs
+to lower the entry barrier. Those programs allow anyone
+to contribute without requiring an official
+\printurl{wiki.debian.org/DebianDeveloper}{Debian Developer} status,
+obtaining of which requires going through an often lengthy
+\printurl{www.debian.org/devel/join/newmaint}{Debian New Maintainer}
+process. Moreover, the Debian policy is not requiring any kind of
+a \emph{Contributor Agreement}, thus ownership for any contributed work
+remains with the authors which is an important insensitive in the true
+spirit of open-source. As a result, anyone
+interested can easily contribute and acceptance might be only a couple of emails away.
% Should the Google Code-In and Google Summer of Code be mentioned?
% What else would we have than those Google activities?
@@ -648,18 +659,23 @@
%The strategy of \DebianMed is
%to stay strictly inside Debian -- so even if manpower is a problem
-\DebianMed understands itself as a part of Debian. The
-whole infrastructure around it will stay solid and does not drain extra
-for the \DebianMed subcommunity. Admittedly, quite frequently the packaging
-for \DebianMed does mean to provide packages that are of interest for
-e.g. Java programmers at large and this way, the Debian itself profits
-from its blends. Also, the separation of \DebianMed from e.g. Debian Science
-is often artificial.
-But one can rest assured that one can reply on the Debian infrastructure
-and that with the preparation of the .deb package all porting to other
-architectures,
-running an online repository and mirrors or to provide a bug
-tracking system etc. is all just already there.
+\DebianMed is not a derived distribution and is a part of the
+Debian project. \DebianMed relies on the core Debian infrastructure (e.g. build farm
+across variety architectures, online repositories and mirrors, bug
+tracking system) and only complements it with an additional thin
+layer yet again functioning within Debian infrastructure. That guarantees that overall development system remains robust
+and not requiring extra effort from the \DebianMed sub-community.
+Moreover, adherence to common principles and organization
+helps \DebianMed project members to improve efficiency and share
+overall maintenance cost since many actions could be done on the
+entire pool of the maintained packages at once. Admittedly, quite
+frequently software products maintained by \DebianMed are of generic
+utility, \emph{e.g.} Java or Python libraries, and thus of interest to the
+Debian audience outside of the target scope of \DebianMed -- Medicine,
+as a result benefitting Debian as a whole. Due to significant
+overlap, boundaries between different blends are not clearly defined and
+the separation of \DebianMed from e.g. Debian Science is often
+artifactual.
\begin{figure}[!htp]
\centering
@@ -668,30 +684,35 @@
\label{figure:authorstats}
\end{figure}
-The success of this strategy can be proven by a continuous growth for
-instance if the number of packages inside Debian which is interesting
-for health care. Taking the number of dependencies of some
-metapackages into account (see figure \ref{figure:dmstats}) at the
-beginning of the project in 2002 a quite low number of packages useful
-for medical care was available. A nearly linear growth with a
-gradient that perfectly reflects the availability of programs in this
-field can be observed.
+The success of the Debian blends approach finds evidence in e.g. a
+continuous growth of the number of packages inside Debian which are of
+interest for health care. Taking the number of dependencies of some
+metapackages into account (see figure \ref{figure:dmstats}), only a
+small set of packages useful for medical care was available at the
+beginning of the \DebianMed project in 2002. A nearly linear growth
+with a gradient that perfectly reflects the availability of programs
+in this field can be observed.
-This growth of the output of a project is an important part but we
-also try to measure the commitment of the people involved in the
-project. It has to be ensured that fresh blood is flooding into the
-project to make sure it can cope with the normal loss of supporters
+Besides the growth of the output of a project it is useful to
+characterize the commitment of people involved in the
+project. It is important to ensure that fresh blood is coming into the
+project to compensate for the normal loss of supporters
which always happens in Free Software projects (people find new jobs
with different orientation or less spare time for private reasons
-etc.) A raw measure for the activity of members might be their mails
+etc.). A raw measure for the activity of members might be their mails
to the project mailing list. Figure \ref{figure:authorstats}) shows
-the number of mails of the ten most active posters of the \DebianMed
+the number of mails from the ten most active posters on the \DebianMed
mailing list. This graph shows that the number of active supporters
was growing constantly in the first years and is now at some constant
-level.
+level. % yoh: yes -- it is at 10, due to initial selection... ;-)
+ % imho either different conclusions are due (# of packages
+ % increases, email traffic decreases -- more efficient - more
+ % work, less words), or plot should be different to show actually
+ % a number of mailing lists participants
% I would not show that
-Considering that some technical discussion was moved to the packaging
+Considering that some technical discussions initiated at \DebianMed
+mailing lists quite often naturally migrate to the packaging
list (see Figure \ref{figure:develstats}(a)) the number of postings of
the most active people remained quite constant and only one member of
the team became inactive (while some new people came in but are not
@@ -707,23 +728,26 @@
\label{figure:develstats}
\end{figure}
-The most active people who committed packaging code are shown in
+The most active people committing packaging materials are shown in
Figure \ref{figure:develstats}(a). In the last year 26 developers did
-1108 commits in the SVN and since \DebianMed has started 47 developers
+1108 commits to the SVN and since the beginning of \DebianMed, 47 developers
did 5545 commits regarding packaging medical applications or
documentation about the project.
\subsubsection{Backports}
Debian comes in releases. Once a release is out, updates to it are
-constrained on security-sensitive issues. New features may introduce
-regressions and are avoided. For scientific packages and for
+limited primarily to security-sensitive or grave functionality issues.
+New features may introduce regressions and are avoided. That
+guarantees a very stable and robust functioning of the system as a
+whole. For scientific packages and for
packages reacting to continuous changes in the health care system,
-this is not possible. The long established backports service \marginpar{please add ref}
-has now become integrated with Debian and offers updates to
-the latest versions of packages while relying on the libraries - whenever
-possible - that we shipped with the official releases. This
-compromise brings maximal usability and maximal security
+this is not an adequate situation. The long established
+\printurl{backports.debian.org}{Debian backports}
+service has being integrated within the official Debian. It offers updates to
+the latest versions of packages while relying on the core components - whenever
+possible - that were shipped with the official releases. This
+compromise allows to brings maximal usability and maximal robustness
together.
\subsubsection{Role inside Debian}
More information about the debian-med-commit
mailing list