Use static GUIDs in the frab schedule, when possible

[stefanor]

SReview is currently having to use the integer in the talk URL to track talks, as they move around in the schedule. There should be a better way.
https://salsa.debian.org/debconf-video-team/sreview/-/blob/main/scripts/util/schedule_parsers/debconf#L82

The frab XSD defines <event>'s id attribute as being an integer, in a single namespace. To avoid duplicates (because Pages and Talks are separate DB entities in wafer, with their own ID space), we've used the ScheduleItem's ID in the past. But these change when a talk gets rescheduled.

So, let's put more information into the GUID. There's enough room here to namespace kinds of schedule items from each other.

I could also imagine putting Talks, Pages, and other ScheduleItems in separate integer ranges (e.g. 0-10000 for talks, 10000-20000 for pages, etc.), but that gets somewhat hairy. This has the advantage of being simple.

Downside is that the consumer can't determine the talk's integer ID from the XML. There doesn't seem to be an appropriate attribute to share it in. Probably the best option will be to continue to parse the XML.

[stefanor]

@johnjohndoe: This probably doesn't help EventFahrplan, it looks like you use the id attribute, rather than the guid. Any thoughts on this approach?

[johnjohndoe]

EventFahrplan does not support guid yet. See: EventFahrplan/EventFahrplan#319

[hodgestar]

@stefanor It is legal to schedule the same page into multiple schedule items (e.g. we do this in PyConZA for lunch and a few other recurring things), so the page pk may not be unique to an event. Not quite sure what to do about that, so just mentioning it for the moment.

[johnjohndoe]

@saerdnaer, I believe you could share your experience here because you dealt with similar topics in the CCC context.

[yoe]

Thanks, switching SReview to the GUID attribute should be easy (and it doesn't assume that the upstream GUID is an integer, so that's fine).

That just leaves the slug, which I was also parsing from the conf_url attribute. It's not as critical; I can slugify myself if needs be, it's just that it's nicer if my slug and the upstream schedule's slug are the same.

FWIW, the "debconf" script isn't actually being used anymore, the actual script that parses schedules these days is https://salsa.debian.org/debconf-video-team/sreview/-/blob/main/scripts/sreview-import which uses SReview::Schedule::Base subclasses (i.e., https://salsa.debian.org/debconf-video-team/sreview/-/blob/main/lib/SReview/Schedule/Wafer.pm in this case) to do the actual parsing.

I should probably throw those old schedule parsers away by now.

[yoe]

Whoops, actually forgot one thing.

SReview's schedule parser also assumes that if the conf_url is not a string of 3 elements separated by a /, that it then is not a talk and therefore will not be recorded, and will ignore those events. I don't know if this is something that is true for all Wafer schedules, but it happened to be true for past debconfs and so that worked.

It would be nice if there were an explicit attribute to state the type of event, so I can filter on that.

[yoe]

and actually the slug is there, I'm blind :) sorry.

[stefanor]

It is legal to schedule the same page into multiple schedule items (e.g. we do this in PyConZA for lunch and a few other recurring things), so the page pk may not be unique to an event. Not quite sure what to do about that, so just mentioning it for the moment.

That's handled, by using the scheduleitem's PK when a page is scheduled more than once.

[stefanor]

SReview's schedule parser also assumes that if the conf_url is not a string of 3 elements separated by a /, that it then is not a talk and therefore will not be recorded, and will ignore those events. I don't know if this is something that is true for all Wafer schedules, but it happened to be true for past debconfs and so that worked.

It would be nice if there were an explicit attribute to state the type of event, so I can filter on that.

Yeah, I was thinking about that, too.

With the current implementation in wafer, the <type> tag will contain the talk type, or be an empty tag <type/> for a page/bare scheduleitem. This is an optional feature in wafer, so if no talk types are configured, the field would be empty. But we could default to "Talk" for talks in this situation, if that sounds preferable.

[stefanor]

@yoe: Another option would be to say that we fix #615, and then you can just import everything that doesn't have an opt-out, as a talk.

[hodgestar]

I don't think this is probably more useful for schedules than the current situation, so I'm approving.

Ideally we should have some tests for these, but since nothing is failing I assume we didn't have tests before either.

Perhaps a cleaner solution would be to have ScheduleItems be more firmly attached to the talk or pages they are connected to, so that ScheduleItems are not created and deleted all the time while modifying the schedule but only moved around.

[stefanor]

Ideally we should have some tests for these, but since nothing is failing I assume we didn't have tests before either.

Yeah, would probably be good to test.

Perhaps a cleaner solution would be to have ScheduleItems be more firmly attached to the talk or pages they are connected to, so that ScheduleItems are not created and deleted all the time while modifying the schedule but only moved around.

That sounds like a pretty good idea. Make the ScheduleItem's slot be optional, so that we can keep it alive (but dormant) when something is unscheduled.

[yoe]

With the current implementation in wafer, the <type> tag will contain the talk type, or be an empty tag <type/> for a page/bare scheduleitem. This is an optional feature in wafer, so if no talk types are configured, the field would be empty. But we could default to "Talk" for talks in this situation, if that sounds preferable.

Yeah, I had noticed that, and am selecting on that for now. It works for debconf21, which is what I care about in the immediate short term, but having a more "proper" solution where we also figure out that something isn't being recorded and therefore we don't need to care about it would be useful down the line.