launchpad-dev team mailing list archive

[Loïc Minier <loic.minier@xxxxxxxxxx>]

On Tue, Aug 31, 2010, Michael Nelson wrote:
> Consider which diffs are useful and should be available
> ========================================
> 
> This is hard, at least given the column restriction. That is, giving
> the different types of diffs an appropriate textual link in such a
> small space.
> 
> That said, this could be another example of why a drop-down more-info
> section for each row could be very useful. This would allow us to
> present the various diffs without the restriction of the column width.
> 
> Regarding the auto-generation of diffs, Julian's main concern was that
> we'll fill the librarian unnecessarily, but based on Colin's feedback,
> it sounds like we could be sensible about the diff generation. Would
> the following work?
> 
> 1) For packages that have changed in derilucid, but not lucid (ie. the
> lucid version is the last common version), we list only one diff
> (last-common-version to derilucid version), and we don't auto-generate
> as its not necessary for making a decision. (?)

 The lucid -> derilucid diff is basically stuff which should be
 sent to lucid or upstream from derilucid, or maintained as a delta in
 derilucid, or dropped; in the Debian->Ubuntu case this usually happens
 either:
 - when implementing these changes in the derivative
 - when the base version is updated and the derivatives needs to
   merge/rebase

 But the Debian / Ubuntu relation also pushed for transparency about the
 delta between Debian and Ubuntu packages, so it might make sense to
 arrange for up-to-date diffs to be available from Launchpad between the
 base and the derived version.  If the base moved forward the diff is
 useless and should not be generated, in fact such diffs were heavily
 critized in the past.

> 2) For packages that have changed in lucid but not in derilucid (ie.
> the derilucid version is the last common version), we list only one
> diff (last-common-version to lucid version), and we *do* auto-generate
> it, as it will be required to make the decision to sync.

 Makes sense, besides these inter-uploads diffs are already generated in
 lucid.

> 3) For packages that have diverged (changes in both), we list two diffs:
>   * last-common-version to derilucid version
>   * last-common-version to lucid version
> and we auto-generate both so that

 Makes sense

> Obviously we need to ensure that we remove references to diffs once
> package differences are resolved (so the librarian isn't filled up)
> 
> Colin mentioned: "You never really want a diff from the current
> version in Lucid to the current version in Derilucid unless one of
> those is also the common version. Otherwise you have this unreadable
> diff.". I'd assumed this diff would be necessary in the following
> scenario:
>  1) New version uploaded to Derilucid
>  2) Derilucid changes merged upstream and uploaded, resulting in a new
> Lucid version, at this point, although the currently published version
> numbers are different, the diff of current version in Lucid to current
> version in Derilucid would show you that you can now sync wouldn't it?
> (ie. there would just be small changelog differences?). Let me know
> anyway.

 You could also see that by comparing the diffs from the last common
 version to the latest version in both archives; it's a manual process,
 but I don't expect a diff such as proposed above to help in most cases,
 it would mostly distract 90% of the time.

-- 
Loïc Minier