search

bgamari / trac-to-remarkup

Moved to GitLab: https://gitlab.haskell.org/bgamari/trac-to-remarkup
https://gitlab.haskell.org
BSD 3-Clause "New" or "Revised" License
2 stars 0 forks source link

Redundant CC metadata updates still occur #42

Open bgamari opened 5 years ago

bgamari commented 5 years ago

https://gitlab.staging.haskell.org/ghc/ghc/issues/16070 https://gitlab.staging.haskell.org/ghc/ghc/issues/16146

bgamari commented 5 years ago

I suspect this is because we don't resolve usernames to their GitLab equivalents. This needs to be fixed.

bgamari commented 5 years ago

Hmm, actually it looks like we do resolve gitlab usernames. In this case I have no idea what is going wrong here.

bgamari commented 5 years ago

Oh, I see what's going on here: we add/remove the committed subscription changes to the un-mapped CC-list.

bgamari commented 5 years ago

Never mind, that's clearly not the issue either. Sigh.

tdammers commented 5 years ago

IIUC, the issue is a much more conceptual one. In TicketImport.hs:463, we change the ticketCC field such that its new value no longer contains any of the users we have just subscribed or unsubscribed. But this is wrong. What we want instead is:

  1. "Unwrap" the Update into per-userID Updates (that is, we would want to go from Update (Set UserID) to something like Map UserID (Update ()))
  2. Cull the updates for the users we have handled via subscribing / unsubscribing
  3. Reassemble the Map UserID (Update ()) into an Update (Set UserID)

Or, alternatively (and this is probably the easier solution): Just cull the user IDs we have handled from both old and new values in the Update.

tdammers commented 5 years ago

936eb4ac77cb8f24ae4ab1098c52bbdd2a14abe6 implements the alternative solution (cull user IDs from both old and new values). Seems to work, though testing against a pristine install seems prudent.