← Back to team overview

clicompanion-devs team mailing list archive

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

 

On Mon, Nov 21, 2011 at 4:55 AM, Matthew Byers <faintstlsaint@xxxxxxxxx>wrote:

> This looks great and seems proven effective. Lets blueprint these and
> start working back AS A TEAM again.
>
>
> On Sun, Nov 20, 2011 at 6:32 AM, Jonathan Marsden <jmarsden@xxxxxxxxxxx>wrote:
>
>> 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
>>
>> --
>> Mailing list: https://launchpad.net/~clicompanion-devs
>> Post to     : clicompanion-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~clicompanion-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> God Bless
>
> --
> Mailing list: https://launchpad.net/~clicompanion-devs
> Post to     : clicompanion-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~clicompanion-devs
> More help   : https://help.launchpad.net/ListHelp
>
>


I started a blueprint called
release-plan-1.1<https://blueprints.launchpad.net/clicompanion/+spec/release-plan-1.1>

This will contain the tasks involved with getting the application into a
tarball and put up on the launchpad page (released).
The second part dealing with getting CLI Companion packaged and into debian
is a separate blueprint found
here<https://blueprints.launchpad.net/clicompanion/+spec/getting-package-into-debian>
.
I put in the Whiteboard at the bottom of each blueprint a Work Item list so
we can see who is doing what.

-- 
Duane Hinnen
duanedesign@xxxxxxxxx
skype: duanehinnen

References