DeveloperDocumentation
|
Size: 3427
Comment: wip
|
Size: 4488
Comment: redaction and sentences wip
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 23: | Line 23: |
| The list below is a list of topics to cover and a sketch of the content for each one. The organisation of the content will be that from the DDR, with appropriate additions. fixme editing here | The list below is a list of topics to cover and a sketch of the content for each one. The organisation of the content will be that from the DDR, with appropriate additions, so not necessarily in the order listed here. |
| Line 25: | Line 25: |
| * BreezyReleaseSchedule (don't copy content of this page, refer to it) * DeveloperResources (which should become a navigation page if not be completely deleted) * Different approaches to packaging, eg: `debian/rules` approaches (by-hand, debhelper, cdbs); patch systems (whether to use one, which one to use). * Who to talk to to decide whether to make a particular change/upload - areas of responsibility |
=== Specific topics and processes to cover === The top of the UDR will say which Ubuntu release the document relates to, and how to find versions for other releases (so that it is straightforward to have different process documents for eg breezy vs. dapper) The UDR will document when and how to make ftp-master requests including syncs and package removals, including how to contact the ftp-masters. We will say who to talk to to decide whether to make a particular change/upload: that you should usually just go ahead and make change covered by own area of responsibility (which may be a package, or some cross-package property), and that for other things it's probably best to ask someone. We'll explain how to find out who last touched a package. And the UDR will warn about what to do for changes that may cause compatibility problems or require corresponding changes to other packages. === Information to be moved from elsewhere === Content should be transferred from DeveloperResources (which should become a navigation page), and the UDR will link to DeveloperResources. === Information about packaging === Several topics about the construction of packages need to be covered, including: The differences in metadata between unmodified Debian source packages, Ubuntu-specific source packages, and Debian packages modified for Ubuntu. The different approaches to packaging will be covered briefly, including specifically common approaches to constructing `debian/rules`, such as straightforward construction by-hand, debhelper, and cdbs; we will make some recommendations about when to use and when not to use these particular tools (eg, that most Gnome packages use cdbs). Patch systems will also be described, and some advice given about whether to use one and which one to use. We will cover dpatch and cdbs at least, as well as reviewing manual approaches. BreezyReleaseSchedule (don't copy content of this page, refer to it) |
| Line 30: | Line 54: |
== BOF notes from Thursday == say at top which ubuntu release the doc describes the processes for how to build package - ubuntu-specific packages - ubuntu diffs from debian packages - syncs - package removals |
|
| Line 43: | Line 57: |
| fine to make change covered by own area of responsibility for other things probably best to ask someone how to find out who last touched package compatibility problems / needed changes to other packages / communications |
|
| Line 55: | Line 65: |
wiki/DeveloperResources becomes link list and referred to in document |
Status
Summary
We should have well-organized developer-oriented documentation for our various tools and procedures, including freeze exceptions, merge-o-matic, seeds and their germination, and much, much more.
Interpretation and overall plan
During the first UBZ BOF, we concluded that the best way to achieve this would be to:
Create an Ubuntu Developers' Reference, which would be derived in the usual way (with a ubuntuNN version etc.) from the Debian Developers' Reference.
As well as deleting or replacing Debian-specific content from the DDR, we will transfer content from process-related wiki.ubuntu.com pages.
The Ubuntu Documentation Team will of course be consulted, but the UDR will be maintained primarily by Ubuntu developers since (a) much of the proposed (non-Debian) content is currently known only to Ubuntu developers and (b) the audience consists of Ubuntu developers.
Areas to cover (or consider covering)
The list below is a list of topics to cover and a sketch of the content for each one. The organisation of the content will be that from the DDR, with appropriate additions, so not necessarily in the order listed here.
Specific topics and processes to cover
The top of the UDR will say which Ubuntu release the document relates to, and how to find versions for other releases (so that it is straightforward to have different process documents for eg breezy vs. dapper)
The UDR will document when and how to make ftp-master requests including syncs and package removals, including how to contact the ftp-masters.
We will say who to talk to to decide whether to make a particular change/upload: that you should usually just go ahead and make change covered by own area of responsibility (which may be a package, or some cross-package property), and that for other things it's probably best to ask someone. We'll explain how to find out who last touched a package. And the UDR will warn about what to do for changes that may cause compatibility problems or require corresponding changes to other packages.
Information to be moved from elsewhere
Content should be transferred from DeveloperResources (which should become a navigation page), and the UDR will link to DeveloperResources.
Information about packaging
Several topics about the construction of packages need to be covered, including:
The differences in metadata between unmodified Debian source packages, Ubuntu-specific source packages, and Debian packages modified for Ubuntu.
The different approaches to packaging will be covered briefly, including specifically common approaches to constructing debian/rules, such as straightforward construction by-hand, debhelper, and cdbs; we will make some recommendations about when to use and when not to use these particular tools (eg, that most Gnome packages use cdbs).
Patch systems will also be described, and some advice given about whether to use one and which one to use. We will cover dpatch and cdbs at least, as well as reviewing manual approaches.
BreezyReleaseSchedule (don't copy content of this page, refer to it)
- Describe seeds and germination
When to make changes
- - who to contact for advice / input / info about correct change to make - who to tell how after you've made your change / patch (what to do with patch) - who to ask before uploading (freezes, universe vs. main) - what to do after upload
- - expect email - check build logs
How we handle translations
chroots
patch systems etc.
how to handle bugs
- (bug handling practices bof)
tools people might find helpful
- pbuilder sudo lintian / linda piuparts
Who is responsible for various important subsystems
- - kernel team, #ubuntu-kernel - docs team, #ubuntu-docs - universe packages, #ubuntu-motu
- ..?
How to merge new Debian or new Upstream or external Repositories
- merge-o-matic
How to import from Debian
backports
- where to find them how to be nice to backporters who runs backports
When to not make changes
- - freezes
how to get upload rights
- main vs universe (ref) motu
wiki.ubuntu.com/REVU
get rid of
- introdeveloperdocs (at least, not have it in main) (also is Ubuntu-native with wrong version)
registering gpg key
- launchpad ?
DeveloperDocumentation (last edited 2011-12-10 01:28:55 by static-50-53-26-176)