Diablo Extras repository proposal
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.