[07:36] sarnold: that is a good question, to which I don't know the answer... [08:01] sarnold: it's ordered by the creation date of the history for the sourcepackage, but displays the date of the last action in the history. [08:02] (creation can be uploaded/copied, etc) [19:07] tomwardill: that's confusing enough in this case but everything is displayed on the one page -- is it possible for 'new' events to be hidden on later pages? eg a package built six months ago just now copied into the archive or similar? === heroux_ is now known as heroux [21:02] sarnold: Copies create a new publication record, so that's not possible, no [21:03] cjwatson: aha, nice, thanks [21:05] sarnold: The lifecycle of a given row in that table (a SourcePackagePublishingHistory row in the DB) is only within a given "location" in the archive (the target (a.k.a. series), pocket, component, and section columns) - the status of that record can change, but any other change creates a new row [21:07] I agree the sorting is confusing, but I'm not convinced it would be much less confusing if the rows were sorted by the order of the displayed date :) [21:17] cjwatson: hah, yeah, I always spend a fair amount of time with these publishing history tables whenever I want to understand something; but I don't think I'd ever seen them in anything except chronological order -- what's the sort order on this? [22:09] sarnold: (sourcepackagepublishinghistory.datecreated DESC, sourcepackagepublishinghistory.id DESC) [22:09] sarnold: The latter is mostly just a tie-breaker to produce unambiguous tests [22:10] cjwatson: okay, cool, so there is an underlying chronologicalness to it all [22:13] sarnold: Right, it's just that the date shown in the table is BasePublishingRecordView.date_last_changed which is an attempt to show a last-changed date in a way that makes most sense depending on the publishing status: if the status is pending it uses datecreated, if it's published it uses datepublished, if it's superseded it uses datesuperseded, etc. [22:17] cjwatson: if you wouldn't mind .. consider 2.02~beta2-36ubuntu3.26 -- it was deleted from xenial proposed a day after it was superceded in xenial updates [22:18] cjwatson: did the 'deleted' line have a different Date: printed on the column during that day? [22:18] ie, did it match the 'superceded' line? perhaps with 'pending deletion' or similar as the status? [22:37] sarnold: I don't believe that Deleted publication was ever in the Superseded status; it was previously Published, during which time it would have shown the date that you see if you expand the row and look at the "Published on" line [22:38] (and you can hover over the date to get a more exact timestamp) [22:38] sarnold: I feel like this is a bit of a game of infinity questions and maybe we could help more effectively if we knew what you were getting at? [22:38] cjwatson: sorry, I explained it poorly; there's currently two entries for 2.02~beta2-36ubuntu3.26 visible on the first page .. [22:39] sarnold: Yes, because they're in two different publication contexts [22:39] cjwatson: well, strictly speaking, at this point it's just my curiousity, and you're right, that's an endless supply :) [22:39] sarnold: There's one record for xenial-proposed, and one for xenial-updates [22:39] This is expected [22:39] cjwatson: I (naively) expected the deletion and superceded lines to have the same timestamp [22:40] sarnold: Removals from -proposed are typically currently manual and happen some time after the copy into -updates [22:40] cjwatson: so the fact that they are different timestamps, and out of order, really makes me question my understanding :) [22:41] sarnold: At some point I hope that one of my excellent colleagues will review https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/373942 and allow Ubuntu to improve this workflow :) [22:42] cjwatson: hah :) I remember trying to read through one of these long-neglected merge requests and was immediately reminded just how little I know about launchpad internals :) [22:42] was it this one? who knows :) [22:42] sarnold: But also, the xenial-updates publication there got superseded by a later version some time after both (1) it was itself created by a copy and (2) its xenial-proposed ancestor was deleted [22:43] That MP is ~800 lines of code motion and passing parameters down through multiple layers and 6 lines of actually doing the removal after the copy if instructed to do so :P [22:44] (OK, and some tests in those ~800 lines) [22:46] oh inded, more test than code addition