On Tue, Aug 24, 2010 at 12:23 PM, Michael Nelson <[email protected]> wrote: > 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'
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 <[email protected]> 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) _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
