On Mon, 23 Aug 2010 09:02:57 +0200, Michael Nelson <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
