#86 Stating target repo of a patch/MR

Open
opened 2 months ago by fr33domlover · 2 comments

If a merge request gets represented as a MergeRequest or Merge or Offer, then the source and target repo/branch can quite naturally be specified using origin and target.

But if a merge request or a patch is just a Ticket with an attachment, how does it specify the target repo/branch?

One possibility is to specify target or context in the patch itself. Then, if we have an OrderedCollection of patch versions (see #72), each Patch in the collection would specify that target/context.

If a merge request gets represented as a `MergeRequest` or `Merge` or `Offer`, then the source and target repo/branch can quite naturally be specified using `origin` and `target`. But if a merge request or a patch is just a `Ticket` with an `attachment`, how does it specify the target repo/branch? One possibility is to specify `target` or `context` in the patch itself. Then, if we have an `OrderedCollection` of patch versions (see #72), each `Patch` in the collection would specify that `target`/`context`.
fr33domlover commented 2 months ago
Collaborator

I think my favorite right now is to use a Ticket (to represent the work item, with due date and assigned person and priority and so on) in combination with Offer (to represent the merge request, with the origin repo/branch and target repo/branch), like this:

{ "@context": "...",
  "id": "https://...",
  "type": "Ticket",
  "attachment": {
    "type": "Offer",
    "origin": "...",
    "target": "...",
    "object": {
      "type": "OrderedCollection",
      "totalItems": 1,
      "orderedItems": [
         { "id": "...",
           "type": "Patch",
           "attributedTo": "...",
           "mediaType": "...",
           "content": "..."
         }
      ]
    }
  }
}

(The Offer and/or the OrderedCollection and/or the patches could have ID URIs and/or be in separate documents; putting everything together here just for simplicity of example)

I think my favorite right now is to use a `Ticket` (to represent the work item, with due date and assigned person and priority and so on) in combination with `Offer` (to represent the merge request, with the origin repo/branch and target repo/branch), like this: ``` { "@context": "...", "id": "https://...", "type": "Ticket", "attachment": { "type": "Offer", "origin": "...", "target": "...", "object": { "type": "OrderedCollection", "totalItems": 1, "orderedItems": [ { "id": "...", "type": "Patch", "attributedTo": "...", "mediaType": "...", "content": "..." } ] } } } ``` (The `Offer` and/or the `OrderedCollection` and/or the patches could have ID URIs and/or be in separate documents; putting everything together here just for simplicity of example)
fr33domlover commented 2 months ago
Collaborator

This will be discussed in #88, see there.

This will be discussed in #88, see there.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.