launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

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.

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

Thanks,

James