launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Tue, Aug 31, 2010 at 6:43 PM, Loïc Minier <loic.minier@xxxxxxxxxx> wrote:
> 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.

Great, thanks Loïc - I'll remove it from the mockups.