DebianImportSpecification
|
⇤ ← Revision 1 as of 2008-11-20 17:24:08
Size: 2538
Comment:
|
Size: 5963
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ##(see the SpecSpec for an explanation) | ##(See the SpecSpec for an explanation) |
| Line 12: | Line 12: |
| The discussion will also cover other issues related to DistributedDevelopment, and what we plan to do in the Jaunty cycle. |
|
| Line 21: | Line 19: |
| * Anne wants to merge the upload that was just done to Debian experimental in to the Ubuntu package. * It's deep in to Ubuntu's freeze and Robert finds a patch for a critical bug in a recently uploaded Debian package. The upload also contained lots of changes not suitable for that point in Ubuntu's release process, so he wishes to just merge the critical bug fix. * Thomas wants to examine the differences between the Debian and Ubuntu packages, and then find who changed a particular line that is causing him problems. * Lara wants to take the changes in the Ubuntu package and send them as a diff to the latest Debian package to the Debian maintainer. |
|
| Line 22: | Line 25: |
* We don't have a large amount of history of uploads to Debian. We can only rely on having the versions in the various releases, plus a little more that can be found on e.g. snapshot.debian.net * Investigating the full history of changes to Debian using these branches is not going to be a common activity. |
|
| Line 25: | Line 31: |
| You can have subsections that better describe specific parts of the issue. | Given the Assumptions above it seems that the overhead of re-writing history in the current Ubuntu branches outweighs the benefit of integrating the little Debian history that we have. In addition to this, the benefit of having mergeable branches of Debian available is huge, and so delaying that in order to have a slightly richer historical representation is not beneficial. Therefore the Debian branches will be initialised from the Ubuntu ones. This has the slight drawback that it will give the impression that Debian derives from Ubuntu, and will attribute some old changes to Ubuntu. The first is obviously not true, and while the second may be a problem it will only be some of the changes in some packages, and in all but a very few cases simple examination of the diff including debian/changelog will make it clear what happened. |
| Line 29: | Line 38: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | The tricky part in creating the Debian branches from the Ubuntu ones is to make sure that the merges lead bzr to do the right thing next time a merge is done. The best way to ensure this is to find the most recent version of the Debian package that corresponds to a revision in the Ubuntu branch. The Debian branch is then initialised from that revision. If that version is the last version of the Debian package then nothing else needs to be done, except for the appropriate tags being applied. If it is not then the current Debian source package is imported on to the new Debian branch. If the current Debian version exists in the changelog of the Ubuntu package then it has already been merged by Ubuntu. In that case we need to create the merge so that the state is represented as exactly as possible. To do that we create a new revision on the Ubuntu branch that changes no content, but just adds an extra parent which is the newly imported Debian revision. The difficulty comes when none of the Debian versions are represented as revisions in the Ubuntu branch. There are two possible causes of this. The first is that the Ubuntu and Debian packages share no history. Having branches that share no common history in this case is the right representation. The second is that the branches do share some history, it's just that the shared history isn't captured in our Ubuntu branches. In this case having diverged branches is problematic, for two reasons. The first being that when someone first does a merge in bzr of these packages they may well have to deal with more conflicts than are necessary. The second being that bzr does not make it easy to merge these unrelated branches in such a way that future merges can use the merge information from it (i.e. the resolved conflicts). This is an unsolved problem, and I have emailed the bzr mailing list to ask for suggestions. |
| Line 33: | Line 46: |
| Should cover changes required to the UI, or specific UI that is required to implement this | There should be few UI changes, as everything is already written with the idea of having branches for multiple distributions. |
| Line 37: | Line 50: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | The code is already written to handle updating both sets of branches in an ongoing fashion, maintaining merge links between them. It needs to be extended to do the initialisation, but with the existing code this shouldn't be too much work. |
| Line 41: | Line 54: |
| 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. |
There is no migration needed for the existing branches, as they are not being re-written to integrate the Debian branches. |
| Line 48: | Line 58: |
| It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. This need not be added or completed until the specification is nearing beta. |
Branching the Debian and Ubuntu branches of a package that is newer in Debian than in Ubuntu, and then performing a merge in bzr. This merge should give no unexpected conflicts. |
| Line 54: | Line 62: |
| This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. | As stated above there is an unresolved issue of how to handle packages where the shared history between Debian and Ubuntu isn't captured in the Ubuntu branches. While it won't affect too many packages it will be some of our most important packages that are affected I imagine. I have asked for assistance from the bzr developers for the technical aspects. If there are no solutions there then I will examine other methods to alleviate the problem. |
| Line 56: | Line 64: |
| == BoF agenda and discussion == Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. |
== Discussion == |
Launchpad Entry: distributed-development-debian-import
Created: 2008-11-20
Contributors: JamesWestby, RobbieWilliamson, ColinWatson, RobertCollins and others
Packages affected: bzr, bzr-builddeb
Summary
The next stage of DistributedDevelopment/Specification is to provide branches of both Debian and Ubuntu, with shared revision history. This specification is about how we get there from where we are now.
Rationale
Ubuntu development is based on Debian, most of our packages come from there, and we regularly merge changes from there. Just having Ubuntu in bzr has limited benefit without also having Debian in bzr, so we want to make Debian import branches available, with a shared revision history, allowing you to merge from Debian in bzr.
Use Cases
- Anne wants to merge the upload that was just done to Debian experimental in to the Ubuntu package.
- It's deep in to Ubuntu's freeze and Robert finds a patch for a critical bug in a recently uploaded Debian package. The upload also contained lots of changes not suitable for that point in Ubuntu's release process, so he wishes to just merge the critical bug fix.
- Thomas wants to examine the differences between the Debian and Ubuntu packages, and then find who changed a particular line that is causing him problems.
- Lara wants to take the changes in the Ubuntu package and send them as a diff to the latest Debian package to the Debian maintainer.
Assumptions
- We don't have a large amount of history of uploads to Debian. We can only rely on having the versions in the various releases, plus a little more that can be found on e.g. snapshot.debian.net
- Investigating the full history of changes to Debian using these branches is not going to be a common activity.
Design
Given the Assumptions above it seems that the overhead of re-writing history in the current Ubuntu branches outweighs the benefit of integrating the little Debian history that we have. In addition to this, the benefit of having mergeable branches of Debian available is huge, and so delaying that in order to have a slightly richer historical representation is not beneficial.
Therefore the Debian branches will be initialised from the Ubuntu ones. This has the slight drawback that it will give the impression that Debian derives from Ubuntu, and will attribute some old changes to Ubuntu. The first is obviously not true, and while the second may be a problem it will only be some of the changes in some packages, and in all but a very few cases simple examination of the diff including debian/changelog will make it clear what happened.
Implementation
The tricky part in creating the Debian branches from the Ubuntu ones is to make sure that the merges lead bzr to do the right thing next time a merge is done.
The best way to ensure this is to find the most recent version of the Debian package that corresponds to a revision in the Ubuntu branch. The Debian branch is then initialised from that revision. If that version is the last version of the Debian package then nothing else needs to be done, except for the appropriate tags being applied. If it is not then the current Debian source package is imported on to the new Debian branch. If the current Debian version exists in the changelog of the Ubuntu package then it has already been merged by Ubuntu. In that case we need to create the merge so that the state is represented as exactly as possible. To do that we create a new revision on the Ubuntu branch that changes no content, but just adds an extra parent which is the newly imported Debian revision.
The difficulty comes when none of the Debian versions are represented as revisions in the Ubuntu branch. There are two possible causes of this. The first is that the Ubuntu and Debian packages share no history. Having branches that share no common history in this case is the right representation. The second is that the branches do share some history, it's just that the shared history isn't captured in our Ubuntu branches. In this case having diverged branches is problematic, for two reasons. The first being that when someone first does a merge in bzr of these packages they may well have to deal with more conflicts than are necessary. The second being that bzr does not make it easy to merge these unrelated branches in such a way that future merges can use the merge information from it (i.e. the resolved conflicts). This is an unsolved problem, and I have emailed the bzr mailing list to ask for suggestions.
UI Changes
There should be few UI changes, as everything is already written with the idea of having branches for multiple distributions.
Code Changes
The code is already written to handle updating both sets of branches in an ongoing fashion, maintaining merge links between them. It needs to be extended to do the initialisation, but with the existing code this shouldn't be too much work.
Migration
There is no migration needed for the existing branches, as they are not being re-written to integrate the Debian branches.
Test/Demo Plan
Branching the Debian and Ubuntu branches of a package that is newer in Debian than in Ubuntu, and then performing a merge in bzr. This merge should give no unexpected conflicts.
Unresolved issues
As stated above there is an unresolved issue of how to handle packages where the shared history between Debian and Ubuntu isn't captured in the Ubuntu branches. While it won't affect too many packages it will be some of our most important packages that are affected I imagine. I have asked for assistance from the bzr developers for the technical aspects. If there are no solutions there then I will examine other methods to alleviate the problem.
Discussion
DistributedDevelopment/DebianImportSpecification (last edited 2009-11-02 10:14:07 by lec67-4-82-230-53-244)