← Back to team overview

clicompanion-devs team mailing list archive

Application and Package release processes (was: Re: Reviews, and expected freeze length )

 

On 11/19/2011 02:58 AM, bdfhjk wrote:

> Please understand me correctly - I only sent our package for review
> to DD and received reply, what is to do before release to debian. The
> most of work are done.


That is a *packaging* review, right?  Not an application review.  So,
with the possible exception of fixing any copyright and licencing issues
in the application, no application freeze was needed for that at all.

> Now we haven't strict freeze. I only proposed to concentrate at bug
> fixing, not new features - and that is what we are doing.


OK... that's not what I thought you said at all.  Also, how can a
packaging review of a package of clicompanion 1.1 happen, if
clicompanion 1.1 is not released yet?

> Fell free to merge your branches with trunk.


OK, will do.

> Before I sent one more time our package to review, we should fix all
> major bugs.


Here is a proposed release process for the application, and for the
package.  They are separate.

Before we get a clicompanion package into Debian, at *minimum*, I think
we need to:

 (1) Test installing (from source) and running clicompanion on Debian,
and make sure all commands in the supplied command library actually work
in a default i386 Debian desktop installation.

 (2) Test running the application on a variety of machines (and virtual
machines) and DEs: i386 and amd64, Unity, GNOME2 maybe, GNOME3, KDE,
high res screens and small lower res netbook screens, etc.).

 (3) Fix all release critical application bugs (are clicompanion bugs
being tagged in LP, so we can easily see which are release critical?).
This includes any release critical bugs arising from the release testing
done in (1) and (2), and any remaining licencing or copyright issues for
every file in the application source tree.

 (4) With Duane's approval as team leader, tag the bzr source tree as
being clicompanion-1.1, and then release clicompanion 1.1 in source
tarball form, make it available for download, and publicize that release
appropriately.

ONLY THEN, when clicompanion 1.1 truly exists, we can move on to
packaging, and:

 (5) Package clicompanion 1.1

 (6) Test the package carefully and thoroughly in both Debian sid and in
Ubuntu Precise, on multiple machines and DEs (i386 and amd64, Unity,
GNOME2 maybe, GNOME3, KDE).  Perhaps test backports to older releases of
Ubuntu (10.04 LTS for example), if testing resources allow that.

 (7) We may also want to test what happens if you install the package on
machines that are already running older (packaged or unpackaged)
versions of clicompanion -- do they upgrade cleanly?

 (8) Ask a friendly DD for review of the package, if appropriate.

 (9) Put out an RFS for it, so we get a sponsor who can upload it into
Debian unstable (this can be the same friendly DD as in step (8)).  Have
the sponsor check and upload the source package for us.

 (10) Monitor bug feedback (in the Debian BTS) and build feedback (on
buildd.debian.org) etc. from the release to unstable, using
qa.debian.org and the PTS at packages.qa.debian.org, address any issues
found, and go back to step (9) for a reupload if needed.

 (11) If all goes well, the package will be migrated into Debian
testing, and this package release of clicompanion is complete.

 (12) Celebrate!  We did it :)

Then, we decide what the planned set of enhancements and bug fixes for
the next version is, consider packaging for other distributions (Fedora?
SuSE? Arch?  Even FreeBSD?) ... and then we start the development
process all over again :)

I'm not a DD or MOTU, because it takes a lot of time and consistent work
to become one; but if you want to check out the packages I have got into
Debian and Ubuntu this way, and their current status, see

  http://qa.debian.org/developer.php?login=jmarsden%40fastmail.fm

Jonathan


Follow ups

References