launchpad development|
Size: 4218
Comment: add signing of packages
|
Size: 5684
Comment: to be more precise 'into the primary archive' not into main
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Build from branch into main = | = Build from branch into the primary archive = |
| Line 6: | Line 6: |
| '''[[LEP]]:''' https://dev.launchpad.net/LEP/BuildFromBranchIntoMain <<BR>> | '''[[LEP]]:''' https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary <<BR>> |
| Line 17: | Line 17: |
| ''What value does this give our users?'' | By allowing Ubuntu developers to build directly from a branch into the primary archive of Ubuntu, we would: |
| Line 19: | Line 19: |
| * It removes one unnecessary step. * It moves us closer to keeping all code in branches and being able to work with it there. |
* remove one unnecessary step. * move closer to keeping all code in branches and being able to work with it there, thereby avoiding confusion about whether a branch is in use for a particular package or not. * encourage use of branch-based release management features like merge proposals (currently hard to enforce since people can bypass them by uploading directly) |
| Line 22: | Line 23: |
| ''What costs does this impose on our users?'' | === Risks === |
| Line 24: | Line 25: |
| * If the server-side building of packages does not work reliably, they will be blocked from uploading. If we retain source package uploads at least as a transitional option there will be an escape from this. | If the server-side building of packages does not work reliably, users will be blocked from uploading. We can provide as escape from this by retaining source package uploads at least as a transitional option. |
| Line 26: | Line 27: |
| * Errors in packaging may be more difficult to see, understand, or debug if they happen on a server rather than locally. However, developers will still have the option to build the package locally. | Errors in packaging may be more difficult to see, understand, or debug if they happen on a server rather than locally. However, developers will still have the option to build the package locally. |
| Line 28: | Line 29: |
| ''Why are we doing this now?'' <<BR>> ''What value does this give our users? Which users?'' Background: |
'''Background:''' |
| Line 52: | Line 47: |
| * Be as secure as the current dput system. There is great potential for damage here. | * Provide a way to build from current official package branches without uploading a source package and without using manually maintained recipes * Expose this mechanism on the web UI * Expose this mechanism via the web service |
| Line 54: | Line 51: |
| ''What MUST the new behaviour provide?'' | Since the aim is to provide a superior alternative to something that already exists within Launchpad, we '''must''' be at least as good as the current system. Specifically: * As secure. There is great potential for damage here. * As easy to track progress of a build * As fast to build, at least * As easy to use |
| Line 58: | Line 59: |
| * A mechanism for disabling dput uploads, that can be controlled by $WHO Note that if we do the disabling, we'll definitely need to fix Bug:386596 (cannot push to a branch for a new source package) |
|
| Line 60: | Line 64: |
| ''What MUST it not do?'' |
|
| Line 63: | Line 65: |
== Subfeatures == ''Other LaunchpadEnhancementProposal``s that form a part of this one.'' |
|
| Line 78: | Line 76: |
| ''How is this workflow discovered? Is this for official package branches only? How does this work for unofficial branches? What are the workflows for failure cases?'' -- jml [[<<Date(2011-01-31T13:35:23Z)>>]] |
|
| Line 82: | Line 82: |
| * You can build from a branch directly into the main Ubuntu archive | * You can build from a branch directly into the primary Ubuntu archive |
| Line 87: | Line 87: |
| * ''How are you going to measure this?'' -- jml [[<<Date(2011-01-31T13:35:23Z)>>]] | |
| Line 88: | Line 89: |
| * ''How are you going to measure this?'' -- jml [[<<Date(2011-01-31T13:35:23Z)>>]] | |
| Line 92: | Line 94: |
| * For integration testing, it seems like we need a place where Launchpad developers can publish changes into something that looks a lot like the main Ubuntu archive, without actually being that archive. This could be a separate reserved pocket, or it could be a different Launchpad instance | * For integration testing, it seems like we need a place where Launchpad developers can publish changes into something that looks a lot like the primary Ubuntu archive, without actually being that archive. This could be a separate reserved pocket, or it could be a different Launchpad instance |
| Line 94: | Line 96: |
| * We can have bzr-builder degrade to do the same thing as bzr-builddeb. | |
| Line 96: | Line 99: |
| * The things missing from bzr-builder would be: * Control over the changelog message used * Better control over the resulting version number * GPG signatures required for something to end up in Ubuntu (API request isn't GPG signed) * Ability to produce non-native tarballs |
Build from branch into the primary archive
Short description of feature
Contact: MartinPool
LEP: https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary
On Launchpad: build-from-branch bugs
As an Ubuntu developer
I want Launchpad to build source and binary packages from branches
so that I don't have to both push the branch and also dput a source package
Rationale
At the moment, after making a change, Ubuntu developers must use bzr-builddeb to build a source package, and then dput to upload it. This is unnecessary work. Some developers only upload and don't push the branch.
By allowing Ubuntu developers to build directly from a branch into the primary archive of Ubuntu, we would:
- remove one unnecessary step.
- move closer to keeping all code in branches and being able to work with it there, thereby avoiding confusion about whether a branch is in use for a particular package or not.
- encourage use of branch-based release management features like merge proposals (currently hard to enforce since people can bypass them by uploading directly)
Risks
If the server-side building of packages does not work reliably, users will be blocked from uploading. We can provide as escape from this by retaining source package uploads at least as a transitional option.
Errors in packaging may be more difficult to see, understand, or debug if they happen on a server rather than locally. However, developers will still have the option to build the package locally.
Background:
Stakeholders
- Ubuntu developers
- Linaro developers
- Ubuntu Technical Board
- James Westby
- Kiko Reis
- Ubuntu technical architect (Allison Randall)
- Lamont Jones
Constraints and Requirements
Must
- Provide a way to build from current official package branches without uploading a source package and without using manually maintained recipes
- Expose this mechanism on the web UI
- Expose this mechanism via the web service
Since the aim is to provide a superior alternative to something that already exists within Launchpad, we must be at least as good as the current system. Specifically:
- As secure. There is great potential for damage here.
- As easy to track progress of a build
- As fast to build, at least
- As easy to use
Nice to have
- A mechanism for disabling dput uploads, that can be controlled by $WHO
Note that if we do the disabling, we'll definitely need to fix 386596 (cannot push to a branch for a new source package)
Must not
Out of scope
Workflows
Publish a change into Ubuntu
- User branches from the source package branch.
- Make changes
- Commit
- Push
- Request publication
How is this workflow discovered? Is this for official package branches only? How does this work for unofficial branches? What are the workflows for failure cases? -- jml <<Date(2011-01-31T13:35:23Z)>>
Success
How will we know when we are done?
- You can build from a branch directly into the primary Ubuntu archive
How will we measure how well we have done?
- Number of packages published in this way.
How are you going to measure this? -- jml <<Date(2011-01-31T13:35:23Z)>>
- Reported satisfaction
How are you going to measure this? -- jml <<Date(2011-01-31T13:35:23Z)>>
- Number of packages willing to proceed to turning off source package uploads
Thoughts?
- For integration testing, it seems like we need a place where Launchpad developers can publish changes into something that looks a lot like the primary Ubuntu archive, without actually being that archive. This could be a separate reserved pocket, or it could be a different Launchpad instance
- Whereas recipe builds use bzr-builder, this will probably use bzr-builddeb because no recipe is needed
- We can have bzr-builder degrade to do the same thing as bzr-builddeb.
- Should packages build and publish on every commit, or should there be a separate request?
- Eventually it may be useful to have a per-package, per-distrorelease option to turn off source package uploads for areas we have decided branches are the best option. That isn't needed in the first iteration.
- The things missing from bzr-builder would be:
- Control over the changelog message used
- Better control over the resulting version number
- GPG signatures required for something to end up in Ubuntu (API request isn't GPG signed)
- Ability to produce non-native tarballs
Changes needed
- Installer bzr-builder into buildd vms. (May already be done.)
- If we're not going to build on every commit, then there must be a mechansm to request a build. (Probably a web service api, and a bzr command that calls it.)
- New type of schedule-able job to request a source package be built from a branch. There is already a db enum for it, but we need to add a new build farm job type.
The uploader (or something else?) should sign packages built by the buildds (with which key?). (bug 579870)
- After that, the binary can be built and published by the existing mechanism, so probably no other changes are needed.
- As a follow-on, add a mechanism to turn off/refuse dput uploads.
