launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

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'

>
> Thanks,
>
> James
>