[07:36] <tomwardill> sarnold: that is a good question, to which I don't know the answer...
[08:01] <tomwardill> 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] <tomwardill> (creation can be uploaded/copied, etc)
[19:07] <sarnold> 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?
[21:02] <cjwatson> sarnold: Copies create a new publication record, so that's not possible, no
[21:03] <sarnold> cjwatson: aha, nice, thanks
[21:05] <cjwatson> 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] <cjwatson> 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] <sarnold> 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] <cjwatson> sarnold: (sourcepackagepublishinghistory.datecreated DESC, sourcepackagepublishinghistory.id DESC)
[22:09] <cjwatson> sarnold: The latter is mostly just a tie-breaker to produce unambiguous tests
[22:10] <sarnold> cjwatson: okay, cool, so there is an underlying chronologicalness to it all
[22:13] <cjwatson> 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] <sarnold> 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] <sarnold> cjwatson: did the 'deleted' line have a different Date: printed on the column during that day?
[22:18] <sarnold> ie, did it match the 'superceded' line? perhaps with 'pending deletion' or similar as the status?
[22:37] <cjwatson> 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] <cjwatson> (and you can hover over the date to get a more exact timestamp)
[22:38] <cjwatson> 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] <sarnold> cjwatson: sorry, I explained it poorly; there's currently two entries for 2.02~beta2-36ubuntu3.26 visible on the first page ..
[22:39] <cjwatson> sarnold: Yes, because they're in two different publication contexts
[22:39] <sarnold> cjwatson: well, strictly speaking, at this point it's just my curiousity, and you're right, that's an endless supply :)
[22:39] <cjwatson> sarnold: There's one record for xenial-proposed, and one for xenial-updates
[22:39] <cjwatson> This is expected
[22:39] <sarnold> cjwatson: I (naively) expected the deletion and superceded lines to have the same timestamp
[22:40] <cjwatson> sarnold: Removals from -proposed are typically currently manual and happen some time after the copy into -updates
[22:40] <sarnold> cjwatson: so the fact that they are different timestamps, and out of order, really makes me question my understanding :)
[22:41] <cjwatson> 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] <sarnold> 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] <sarnold> was it this one? who knows :)
[22:42] <cjwatson> 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] <cjwatson> 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] <cjwatson> (OK, and some tests in those ~800 lines)
[22:46] <sarnold> oh inded, more test than code addition