← Back to team overview

launchpad-dev team mailing list archive

Re: Results: derived distro mock-up testing round 2

 

On Tue, 31 Aug 2010 17:16:18 +0200, Michael Nelson <michael.nelson@xxxxxxxxxxxxx> wrote:
> Thanks Matthew for transcribing and summarising all the info - it's
> invaluable. And thanks Peter, Colin and Loïc for taking the time to
> give such feedback.

and thank you for these great notes.
> 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. (?)

Sounds sensible.

> 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.

Agreed.

> 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
>
> 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.

What we do want to see often is the result of merging one in to the
other (usually lucid to derilucid).


Has there been any discussion of not using soyuz's diff generations
stuff and instead linking out to bazaar.launchpad.net? It's not the most
stable thing in Launchpad, but it does allow for dynamic diff
generation, and so everything can be supplied without delay, without
affecting the librarian at all.

Thanks,

James



Follow ups

References