← Back to team overview

launchpad-dev team mailing list archive

Re: Implementation plan for derived distros UI

 

On Fri, Aug 20, 2010 at 6:41 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> On Fri, 20 Aug 2010 12:40:07 +0200, Michael Nelson <michael.nelson@xxxxxxxxxxxxx> wrote:
>> 4. Schema: A DistroSeriesDifference record would require the following fields:
>>   * derived_series (foreign key to the derived series which also tells
>> us the parent series, although see option (a) below).
>>   * parent_source_package_publishing_history
>>   * source_package_publishing_history (see option (b))
>>   * comment (text)
>>   * ignored (boolean)
>
> Are you able to store "ignored always" elsewhere in the model, or did
> that not get included?

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?)

>
>> Schema assumptions:
>>   * we don't need a package_diff nullable foreign key as a query for
>> the packagediff table based on our related source package releases
>> will be fast enough (even when displaying 50 records). We could
>> replace the two source/target package references with a single
>> reference to a PackageDiff if and only if we wanted to generate a diff
>> always (which apparently we don't, as shown in the UI).
>
> I would have no problem with always generating a diff. I assumed the UI
> was like that because you didn't want to pay that cost.

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?

>
>> b) We could also just use source package releases here (like the
>> package diff table), but the source package publishing history enables
>> us to encode a bit more info (like archive). (@Julian: after thinking
>> more about this, I'm not sure why spph is helpful? How we'd use the
>> extra information, or how is it related to a difference between two
>> different versions which should be independent of which archive
>> they're published in?).
>
> Do you need spph in order to have the "sync" button?

I don't see why - getting the spph for a SPR in a distro archive is trivial.

Thanks for the feedback!



Follow ups

References