Diablo Extras repository proposal
(Copyediting) |
m (links) |
||
| (11 intermediate revisions not shown) | |||
| Line 2: | Line 2: | ||
== Objectives == | == Objectives == | ||
| - | * Create a | + | * Create a Diablo repository with a baseline for quality packages |
* Make sure source packages are always available | * Make sure source packages are always available | ||
* Make sure that packages with broken dependencies don't enter the repository | * Make sure that packages with broken dependencies don't enter the repository | ||
| + | * Short-term improvements for Diablo repository. | ||
== Proposal == | == Proposal == | ||
| - | This is a '''DRAFT UNDER DISCUSSION'''. You can help reaching conclusions. Please add your comments to the [[ | + | This is a '''DRAFT UNDER DISCUSSION'''. You can help reaching conclusions. Please add your comments to the [[{{TALKPAGENAME}}|discussion]] page. |
| + | This proposal is part of the [[Extras repository process definition]]. | ||
| - | == Maemo | + | == Maemo Extras repository proposal for Diablo == |
| - | At the moment the quality of packages in | + | 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 | + | === No direct binary uploads to Diablo Extras === |
| - | For | + | For Diablo, we have the ability to start off with a clean slate and an empty repository. There is an ongoing effort ([https://garage.maemo.org/extras-assistant/maemo_extras_chinook_rebuild.php Chinook] - [https://garage.maemo.org/extras-assistant/maemo_extras_diablo_rebuild.php Diablo]) 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 | + | * All applications must be uploaded to Diablo Extras repository as source packages. |
| + | * These uploads should go through the [http://extras-cauldron.garage.maemo.org/HOWTO.html autobuilder]. | ||
| + | ** 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. | We might want to add more checks later, but don't want to make it impossible for new developers to upload packages. | ||
| Line 23: | Line 28: | ||
The diablo upload queue will be opened when the diablo SDK has been released. | The diablo upload queue will be opened when the diablo SDK has been released. | ||
| - | === Package promotion from | + | === Package promotion from Extras-devel to Extras === |
| - | After the autobuilder builds the package, it will be uploaded to the | + | 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 | + | * 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 | + | * 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 | + | 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. | 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 [[ | + | Feel free to add to the [[{{TALKPAGENAME}}|discussion]]. |
| + | |||
| + | |||
| + | See also [[Diablo Community Project]] | ||
| + | |||
| + | [[Category:Community]] | ||
| + | [[Category:maemo.org]] | ||
| + | [[Category:Diablo]] | ||
Latest revision as of 14:16, 19 April 2010
This proposal is coordinated by Niels Breet.
Contents |
[edit] 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
- Short-term improvements for Diablo repository.
[edit] Proposal
This is a DRAFT UNDER DISCUSSION. You can help reaching conclusions. Please add your comments to the discussion page. This proposal is part of the Extras repository process definition.
[edit] 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.
[edit] No direct binary uploads to Diablo Extras
For Diablo, we have the ability to start off with a clean slate and an empty repository. There is an ongoing effort (Chinook - Diablo) 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 applications must be uploaded to Diablo Extras repository as source packages.
- These uploads should go through the autobuilder.
- 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.
[edit] 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.
[edit] Discussion
Feel free to add to the discussion.
See also Diablo Community Project
- This page was last modified on 19 April 2010, at 14:16.
- This page has been accessed 37,301 times.