launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Tue, Aug 24, 2010 at 12:23 PM, Michael Nelson
<michael.nelson@xxxxxxxxxxxxx> wrote:
> On Mon, Aug 23, 2010 at 4:53 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
>> On Mon, 23 Aug 2010 09:02:57 +0200, Michael Nelson <michael.nelson@xxxxxxxxxxxxx> wrote:
>>> Sure - we can store whatever is needed for the workflow... I must have
>>> missed the use-case for an 'ignored_always'. Can you explain it to me?
>>> (are you expecting the normal 'ignored' boolean to be reset
>>> automatically when a new version is uploaded, where as this one would
>>> never be reset automatically?)
>>
>> Colin pointed out that both are useful.
>>
>> We currently have 'ignored_always' as the sync-blacklist.txt file. We
>> would like 'ignored' to save duplicated work if a particular version
>> doesn't need to be merged, but future ones will.
>
> Great, so we can instead use a status field with values like:
> NEEDS_ATTENTION, CURRENTLY_IGNORED, ALWAYS_IGNORED. Would that work
> for you?
>
>>
>>> AFAIK, it is a cost consideration, but IMO to consider that cost we'd
>>> want to take into account whether the diff is always going to be
>>> consulted (or if in 90% etc.). If it was nearly always used, or if we
>>> new it was always used in certain situations, it would simplify the
>>> workflow to just make sure it was there and didn't need to be
>>> requested. I'm not sure if it was already discussed before I was
>>> involved... Julian? StevenK?
>>
>> Having the button there is fine. Could we measure usage to see if we can
>> find conditions in which pregenerating would be useful?
>>
>> My only concern is that jobs on request aren't very nice for writing API
>> clients against. We have to trigger the job, then poll for the presence
>> of the result. If failure states aren't exposed then we need a timeout
>> too, all of which does not aid usability.
>
> Yep, it'

Yep, it's the same for me with the UI. Julian said that the main
concerns are (1) processing unnecessarily, which also influences (2)
librarian disk usage. That's a great idea to measure usage and see if
we can find the conditions.

Also, the following just occurred to me:

On Fri, 20 Aug 2010 12:40:07 +0200, Michael Nelson
<michael.nelson@xxxxxxxxxxxxx> wrote:
> 4. Schema: A DistroSeriesDifference record would require the following fields:
>   * derived_series
>   * parent_source_package_publishing_history
>   * source_package_publishing_history

Instead of the last two columns, we could instead simply store the
source package name and always look up the most recent publishing for
each distroseries. We'd still be benefiting from these records
providing us with all the identified differences, but the versions
would always be up to date.

On a related note, I'm assuming that comments added for a row (in the
UI), such as "We're waiting for version 1.2.5b" would be comments per
source package name rather than per version... is that correct? (ie.
when Foo 1.2.1 / Foo 1.2.0 is already displayed in the UI, and Foo
1.2.2 is uploaded to the parent, would you expect to see the existing
row updated to Foo 1.2.2 / Foo 1.2.0 or the existing row obsoleted
(with its comments) and a new record for Foo 1.2.2 / Foo 1.2.0
created? I'm assuming the former).

Cheers,
Michael

>   * comment (text)
>   * status (enumeration)