launchpad development|
Size: 3238
Comment:
|
Size: 3476
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| * '''Launchpad entry:''' none yet * '''Created:''' (date) by (your name here) * '''Contributors:''' * '''Depends on:''' Is this spec dependent on the implementation of another spec? If n/a replace this text with "n/a" |
* '''Launchpad entry:''' https://blueprints.edge.launchpad.net/soyuz/+spec/sourcepackage-licenses * '''Created:''' 2008-12-01 by CelsoProvidelo * '''Contributors:''' JulianEdwards |
| Line 17: | Line 16: |
| '''Summary:''' This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. Mention tables being created. | '''Summary:''' This specification describes how sourcepackage licenses will be stored and tracked within Launchpad using the new debian copyright format. See http://wiki.debian.org/Proposals/CopyrightFormat for more information. |
| Line 19: | Line 18: |
| '''Goal/Deliverables:''' Extract and store as much information as possible from the new machine readable copyright format when it's used. | |
| Line 20: | Line 20: |
| '''Goal/Deliverables:''' What do we plan to achieve and what actual things will be released/deployed? '''We will know we have finished when ...''' - complete this sentence and leave in bold format. {{{ e.g. We will know we have finished when we have basic pages in Launchpad on login.launchpad.net that allow someone to do the workflows outlined in the UI Mockups spec.}}} |
'''We will know we have finished when the license relationships expressed in the new copyright format are stored and acessible after a sourcepackage upload is processed.''' |
| Line 38: | Line 34: |
| This section should be a bulleted list of use cases which also include the user experience. Try to address who would use this, how they would use it, and what advantage it would be. | * Richard is a strong GPL-v3 defensor, and to prove his point, he want to produce a report of all sources currently published in ubuntu/jaunty which contains GPL-v3 license code. * Romeu, a release manager of a distribution hosted in Launchpad, wants to audit all the sources published in his release and decided, based on their licenses, which sources can be redistributed on their mirrors. * ... * Juliet, a package reviewer, should be able to inspect the licenses involved in a new source uploaded to ubuntu before accept it. |
Contents |
SourcePackage licenses
Overview
Launchpad entry: https://blueprints.edge.launchpad.net/soyuz/+spec/sourcepackage-licenses
Created: 2008-12-01 by CelsoProvidelo
Contributors: JulianEdwards
Overall Summary
Summary: This specification describes how sourcepackage licenses will be stored and tracked within Launchpad using the new debian copyright format. See http://wiki.debian.org/Proposals/CopyrightFormat for more information.
Goal/Deliverables: Extract and store as much information as possible from the new machine readable copyright format when it's used.
We will know we have finished when the license relationships expressed in the new copyright format are stored and acessible after a sourcepackage upload is processed.
Release Note
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log.
It is mandatory.
Rationale
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.
Use cases
- Richard is a strong GPL-v3 defensor, and to prove his point, he want to produce a report of all sources currently published in ubuntu/jaunty which contains GPL-v3 license code.
- Romeu, a release manager of a distribution hosted in Launchpad, wants to audit all the sources published in his release and decided, based on their licenses, which sources can be redistributed on their mirrors.
- ...
- Juliet, a package reviewer, should be able to inspect the licenses involved in a new source uploaded to ubuntu before accept it.
Assumptions
A list of assumptions should go here. This should include any assumptions about the users, the workflow, the implementation, the system this will reside on, the hardware requirements, access, etc.. Note that these are assumptions that everyone should believe are "business as usual". If you find yourself writing things which aren't, they are requirements and should be documented in the Implementation section below.
User Interface
This section should cover changes required to the UI, or specific UI features that are required to implement this.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. This could include subsections in addition to what is provided in this spec template.
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Schema Changes
What Database changes are you proposing? Do you need a new index created? Proposing a new table? If so, what does it look like?
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
how users will be pointed to the new way of doing things, if necessary. (If your change is big enough, consider using the rollout template.)
Unresolved issues
In this section list out any issues which are unresolved and will impact or block the implementation of this spec.
