[maemo-developers] Application Manager and Extras-devel: Dealing with unstable software

[From: Marius Vollmer]

"ext gary liquid" <liquid at gmail.com> writes:

> If I *choose* to get involved in the xournal beta testing and want to
> obtain it from -devel this should not effect the testing status of
> other applications which I am not focusing upon nor testing.

As far as I understand it from the way it is set up, extras-devel is the
staging area for extras, it is not the place to for long running beta
testing or wild experiments.  If you upload a version of a package to
extras-devel that will not be good enough to be promoted to extras for a
long time, you have cut off your users from updates to your package for
that long time.  That's not good.

Thus, if you have two branches of your software: a released one that
gets updated from time to time with bug fixes, and a development one
where new features are implemented, then extras and extras-devel would
_both_ contain the released branch.  When a update comes out for the
released branch, it first enters extras-devel, and is promoted to extras
after a short time.

I would expect that everybody subscribed to maemo-developers is using
extras-devel, not extras.  A package should only stay a short time in
extras-devel, say a week or two, so that people here have a chance to
catch new bugs.  In other words, packages should probably be promoted to
extras automatically unless someone explicitly blocks them.


Now, where should the development branch go?  The development branch
might not be distributed as packages at all, and everybody who wants to
check it out has to get the source and compile it him/herself.  This is
not unreasonable, especially for libraries.  Most of Open Source is
developed this way; GNOME is only packaged for Debian once it is
released, AFAIK.  (Foresight might package the unreleased GNOME
development platform, but that would be an exception.)

If you do want to package your development branch, you should do it so
that the resulting packages can be installed in parallel with the
packages from the released branch.  Then people opt-in to your beta
testing by installing the development packages.

Making two versions of a library or program installable and useable at
the same time requires some non-trivial extra work and adds complexity
to your software in general.  But it might be worth doing.

If you don't want to do that extra work, you should still produce a
second set of packages for your development branch, but make them
conflict with the ones from the release branch.  Then opting-in to your
beta test means stopping to use the released version.  People can still
opt-out by uninstalling the development version and installing the
released version instead.

If you have packages for your development version, they can be released
via extras-devel and extras like any other package.  They need to be
clearly labeled as a "beta version" or similar.  Putting this into the
name might be enough, or the Application manager could help with that by
using different colors for different kinds of packages.