On Tue, Aug 31, 2010 at 6:03 PM, James Westby <[email protected]> wrote: > On Tue, 31 Aug 2010 17:16:18 +0200, Michael Nelson > <[email protected]> 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.
I've not heard it discussed... but that could be a great idea. I think the soyuz diff generation was assumed because its what has always been used for package diffs (pre-dating package branches)... and I'd wrongly assumed we'd need diffs between the lucid and derilucid version). The unknown factors for me so far are: 1) When a new version of a src package is published, are we guaranteed that the version is already committed to a bzr branch (for derived distros also) (for build from branch of course it is, but normal uploads?) 2) If I have a source publishing record in Launchpad, can I get directly to the bzr branch and rev number even if it hasn't been built via a recipe but is a standard upload (I'll follow that up if no-one beats me to it). _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
