Diablo Extras repository proposal

(Proposal for diablo extras repository.)
(Copyediting)
Line 15: Line 15:
=== No direct binary uploads to diablo extras ===
=== No direct binary uploads to diablo extras ===
-
For diablo we have the ability to start of with a clean slate or an empty repository. There is an [https://garage.maemo.org/extras-assistant/maemo_extras_chinook_rebuild.php effort going on] at the moment to get all source packages from chinook and see if they can be built against a clean chinook and later bootstrap the diablo extras repository with them. After this effort is done we can setup repository access as follows:
+
For diablo we have the ability to start off with a clean slate or an empty repository. There is an [https://garage.maemo.org/extras-assistant/maemo_extras_chinook_rebuild.php ongoing effort] to get all source packages from chinook and see if they can be built against a clean chinook and later bootstrap the diablo extras repository with them. After this effort is done we can setup repository access as follows:
All uploads to the diablo extras repository should go through the [http://extras-cauldron.garage.maemo.org/HOWTO.html autobuilder]. This means that you can only upload source packages of your application to the autobuilder queue. The autobuilder will do some really basic QA, basically it only checks if the package builds. It will also prevent packages with broken dependencies from entering the repository.
All uploads to the diablo extras repository should go through the [http://extras-cauldron.garage.maemo.org/HOWTO.html autobuilder]. This means that you can only upload source packages of your application to the autobuilder queue. The autobuilder will do some really basic QA, basically it only checks if the package builds. It will also prevent packages with broken dependencies from entering the repository.
Line 27: Line 27:
After the autobuilder builds the package, it will be uploaded to the extras-devel repository. This repository is meant to be a playground, testing, experimentation repository. If the developer thinks his package is ready for extras, we have two options:
After the autobuilder builds the package, it will be uploaded to the extras-devel repository. This repository is meant to be a playground, testing, experimentation repository. If the developer thinks his package is ready for extras, we have two options:
-
* the package can be promoted to extras using the promotion interface by the developer
+
* The package can be promoted to extras using the promotion interface by the developer
-
* a group of community volunteers manages all promotion requests and decides if the package quality meets the standards to be promoted to extras.
+
* A group of community volunteers manages all promotion requests and decides if the package quality meets the standards to be promoted to extras.
-
The first option is what we have in place now. We can easily start using that from the start. The advantage is that a developer can easily put the package in extras. A disadvantage is that the developer deems the quality good enough, while it really isn't.
+
The first option is what we have in place now. We can easily start using that from the start. The advantage is that a developer can easily put the package in extras, but the disadvantage is that a developer may deem the quality good enough when it really isn't.
-
The second option take longer to get in place and is quite ambitious, so maybe we need to aim for Fremantle to work this out properly.
+
The second option takes longer to get in place and is quite ambitious, so maybe we need to aim for Fremantle to work this out properly.
== Discussion ==
== Discussion ==
Feel free to add to the [[Talk:Diablo_extras_repository_proposal|discussion]].
Feel free to add to the [[Talk:Diablo_extras_repository_proposal|discussion]].

Revision as of 16:10, 17 June 2008

This proposal is coordinated by Niels Breet.

Contents

Objectives

  • Create a diablo repository with a baseline for quality packages
  • Make sure source packages are always available
  • Make sure that packages with broken dependencies don't enter the repository

Proposal

This is a DRAFT UNDER DISCUSSION. You can help reaching conclusions. Please add your comments to the discussion page.

Maemo extras repository proposal for diablo

At the moment the quality of packages in chinook extras is varying from super to pretty bad. Another problem is that, for most packages, there is no source package available. If we want to break this trend we need to take some measures to ensure at least a baseline quality for packages. Now we have the opportunity to act before diablo gets released, next one will be Fremantle.

No direct binary uploads to diablo extras

For diablo we have the ability to start off with a clean slate or an empty repository. There is an ongoing effort to get all source packages from chinook and see if they can be built against a clean chinook and later bootstrap the diablo extras repository with them. After this effort is done we can setup repository access as follows:

All uploads to the diablo extras repository should go through the autobuilder. This means that you can only upload source packages of your application to the autobuilder queue. The autobuilder will do some really basic QA, basically it only checks if the package builds. It will also prevent packages with broken dependencies from entering the repository.

We might want to add more checks later, but don't want to make it impossible for new developers to upload packages.

The diablo upload queue will be opened when the diablo SDK has been released.

Package promotion from extras-devel to extras

After the autobuilder builds the package, it will be uploaded to the extras-devel repository. This repository is meant to be a playground, testing, experimentation repository. If the developer thinks his package is ready for extras, we have two options:

  • The package can be promoted to extras using the promotion interface by the developer
  • A group of community volunteers manages all promotion requests and decides if the package quality meets the standards to be promoted to extras.

The first option is what we have in place now. We can easily start using that from the start. The advantage is that a developer can easily put the package in extras, but the disadvantage is that a developer may deem the quality good enough when it really isn't.

The second option takes longer to get in place and is quite ambitious, so maybe we need to aim for Fremantle to work this out properly.

Discussion

Feel free to add to the discussion.