7935890 unpick the 'pass cid to event.create' workaround, comment

Authored and Committed by adamwill 8 years ago
    unpick the 'pass cid to event.create' workaround, comment
    
    So now we can wait for composes to appear in PDC before doing
    event creation, we don't need this workaround any more. It's a
    mess, so ditch it. Also comment the situation. To expand on the
    comments a bit:
    
    Right at the moment a 'candidate' compose completes, it is only
    available in a location derivable from its compose ID (not from
    its label). The relevant wikitcms event's version properties,
    however, are derived from the compose's label - when we actually
    decide what the event should be, we get the compose's label and
    say "OK, Alpha-1.5? Then the event is milestone Alpha, compose
    1.5!"
    
    When we're creating the event, we then wind up working *back*
    from the event's version properties to try and get a fedfind
    release instance, in order to generate the download table. We
    call fedfind.release.get_release(release, milestone, compose).
    For the brief period (likely a few seconds to a few minutes)
    where the compose is not in PDC, fedfind will fail to find any
    release for us, because there is just no way to figure out the
    compose ID from the milestone and release at that point.  Once
    the compose is in PDC, fedfind can parse the milestone and
    compose back into a label, ask PDC for the compose ID of the
    compose with that label, and then find the compose based on the
    compose ID.
    
    The other way fedfind can succeed when given a label-y milestone
    and compose is if the compose has been synced to stage, because
    when we sync candidate composes to stage the directory name is
    based on the label, not the compose ID. So fedfind can find
    those just fine without needing to talk to PDC at all. But sync
    usually happens some time *after* PDC import, so PDC import is
    the earliest point at which we can reliably create an event for
    a candidate compose and be sure the download table will work.
    
    An alternative to all this faffing around would be to give up on
    inferring the compose for wikitcms events from their version
    properties and instead *require* a compose ID to be explicitly
    provided at event creation time and have the compose ID for each
    event stored in the wiki somehow, but that'd mean setting up some
    kind of 'metadata' page in the wiki and reading that every time
    we want to find out the compose for a validation event. I dunno
    which is worse.
    
        
file modified
+12 -18
file modified
+4 -16