launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Tue, Aug 31, 2010 at 6:03 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> 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.

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