launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

Hi,

While Matthew is doing the second round of user testing for the
derivative distribution mockups at:

https://dev.launchpad.net/LEP/DerivativeDistributions

we're starting to think about how this UI (or something similar) will
be best implemented. Specifically, the pages that display the package
differences between a derived distro series and its parent:

https://dev.launchpad.net/LEP/DerivativeDistributions?action=AttachFile&do=get&target=derived-series-diffs_5.png

This page (and its siblings - missing packages, unique packages) needs
to display a result set of all the packages that are different between
two distribution series (ie. the latest published version of a package
is different).

It'd be great to get some feedback from stub or other people with more
postgre-foo than me to confirm or deny the following assumptions:

1. This UI will require a new model/database table.
Even if a query is possible to generate the information displayed
there, it would be too slow for a view (?), and would not provide a
way to store extra information such as the comment, or whether the
item is ignored without hacking these onto existing models.

What would be a good model name for these records? DistroSeriesDiff?
DistroSeriesDifference (just to communicate that its not just a
textual diff like PackageDiff)?

2. A job will be required that generates and updates the
DistroSeriesDifference records for the view.

3. When "View diff" is clicked for a specific row, a PackageDiff
record will be created (using the existing infrastructure) to schedule
the diff generation job.

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)

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

Schema options:
a) Instead of derived_series, we could generalise to:
  * from_series (foreign key to the parent of the derived series)
  * to_series (foreign key to the target series)
which would keep the DistroSeriesDifference implementation a bit more
general (and rename parent_spph/spph to
from_source_package_publishing_history/to_source....)

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

Thanks for reading (and hopefully thinking and writing :) ). I'll
integrate any feedback into an implementation plan.
-Michael