On Mon, Aug 23, 2010 at 4:53 PM, James Westby <[email protected]> wrote: > 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.
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 > _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
