| tomwardill | sarnold: that is a good question, to which I don't know the answer... | 07:36 |
|---|---|---|
| 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:01 |
| tomwardill | (creation can be uploaded/copied, etc) | 08:02 |
| 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? | 19:07 |
| === heroux_ is now known as heroux | ||
| cjwatson | sarnold: Copies create a new publication record, so that's not possible, no | 21:02 |
| sarnold | cjwatson: aha, nice, thanks | 21:03 |
| 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:05 |
| 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:07 |
| 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? | 21:17 |
| 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:09 |
| sarnold | cjwatson: okay, cool, so there is an underlying chronologicalness to it all | 22:10 |
| 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:13 |
| 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:17 |
| 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:18 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| cjwatson | (OK, and some tests in those ~800 lines) | 22:44 |
| sarnold | oh inded, more test than code addition | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!