Request For Candidates: Application Review Board

[Stephan Hermann]

Hi Martin,

On Thu, Aug 26, 2010 at 11:56:09AM +0200, Martin Pitt wrote:
> Stephan Hermann [2010-08-26 11:32 +0200]:
> > So, what James and you are thinking about is something like Slackwares tgz format,
> > it's a prebuild binary packaged with tar.gz and put a wrapper around which installs the 
> > simple app under $HOME/Apps/ (example!!!) for user only installations. Therefore the install script 
> > (maintainer script) only needs user permissions. 
> 
> I don't see anything wrong with using .debs for this, and just placing
> restrictions on it -- such as having no maintainer scripts at all, and
> all files in /opt/<packagename>/. There needs to be one exception for
> their .desktop files, of course, but this is orthogonal to the
> packaging format. Ideally we woudl just have a dpkg.d script or
> trigger which integrates new .desktop files in /opt/; I didn't think
> about the details of this yet, but this is clearly a solvable problem.

Well, we could still use .debs as helper for installation.
But what I was thinking about was the barrier for app developer to deal with 
deb specific things.

When I re-read my reply, I thought about something like this (EXAMPLE!!!!):


1. App developer comes up with the source archive.
2. App developer wants to inject the app into ubuntu
3. App developer needs to provide a build manifest in a simple structured format (xml/yaml/whatever)
   1. build manifest (ubuntubuild.xml)
      <?xml version="1.0" encoding="UTF-8" ?>
      <!-- some DTDs for checking if everything is wellformed -->
      <app ubunturelease="{ALL,maverick,natty}">
	<general>
      		<name>Greatest App of the world</name>
		<shortname>grapp</shortname>
      		<sourcearchivename>greatapp-1.0.{tar\.gz,zip,whatever}</sourcearchivename>
      		<author>...</author>
		<email>...</email>
      		<license>GPLv3</license>
      		<copyright>...</copyright>
	</general>
	<build type="{autoconf,ant,maven,mono,cmake,whatever}" prefix="${general/shortname}">
		<!-- if autoconf e.g. -->
		<configureflags>
		  --enable-this
		  --enable-that
                  -with-foobar
		</configureflags>
	</build>
     </app>
    2. Put original source archive and build manifest into a tar.gz 
    3. upload to a special server
4. Review Process
   1. Reviewer declined 
      1. Write automated/manual email to the author why this app was rejected
   2. Reviewer Acknowledged
      1. Write automated email to the author that the app was accepted for inclusion
      2. Trigger 5.
5. Automated app src-deb creator 
   1. fetches this archive and generates a source package from it
   2. created src-deb will be signed with a special key from canonical/ubuntu archive admin (which is not the same as the default ubuntu archive key)
   3. created src-deb will be uploaded to a special buildserver for the <tobenamed> release pocket
6. Buildserver
   1. src-deb does not build correctly
      1. write automated email to the author that the app didn't build successfully, app developer needs to fix that, attached build log
      2. remove everything from the servers
   2. src-deb builds successfully
      1. binary debs will be pushed to archive servers
      2. write automated email to the author with success, your app will be included in ${ubunturelease} and stays there forever or until the ubuntu release is EOL

IMHO we will drop the barrier for app developers, not to concentrate on package building, but on the app itself. If they want to include it into ubuntu, they need to
create the manifest, and we will do the rest, because we know best what needs to be done for a debian package for ubuntu.

All in all, it sounds complicated for setting up the relevant infrastructures, but in
the end, we will have a something more supportable and less work for all of us.

Some things could be added to launchpad as central starting point, other stuff needs to be implemented on infrastructure side.
We are writing those things as opensource, so that interested people could jump onto the wagon and work on those tools/services etc.

And, another point, other distros could use this approach and build packages for their distros, without hasseling app developers to deal with the different pkg building tools.

Regards,

\sh

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100826/9caa3801/attachment.pgp