On Tue, Aug 31, 2010 at 6:43 PM, Loïc Minier <[email protected]> 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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
