#40 Determine where to send tickets

Open
opened 4 months ago by fr33domlover · 7 comments

Tickets, issues, project management etc. are a concept distinct from repositories (repos are just versioned file storage, basically). But these 2 things meet, when you wish you open a ticket on a specific repo. And the question is, how does ForgeFed software decide where to send the ticket? Possible examples:

  • No ActivityPub way to send the ticket; maybe just email the repo's maintainer
  • Send the ticket to the repo maintainer Person actor
  • Send the ticket to the repo team of collaborators
  • Send the ticket to the Repository actor, which perhaps manages tickets in addition to the actual VCS repo
  • Send the ticket to another Repository actor, which may be a repo containing the tickets, a-la distributed bug tracker such as git-bug or Bugs Everywhere
  • Send the ticket to a separate ticket tracker which manages tickets for the repo, and that tracker may be entirely separate software on a separate website

Question: When I have a bug or feature request to submit against a specific repo, how does my client software know where to deliver it? How can it choose among all those options above? We need to decide how it's done because there's no obvious way:

  • Gitolite, Gitosis, cgit, gitweb... manage only repos, not tickets
  • githu8, gitlab, Gogs, Gitea... manage tickets per-repo
  • Some projects have a dedicated fake empty repo used just for tickets
  • Some projects use an external bug tracker such as Bugzilla or Redmine or Trac or Taiga etc.
  • Some projects just say "email bugs to maintainer"
  • Some software supports a variety of project management features including ticket tracking and VCS repos, but neither is a primary feature/object and it's not automatically obvious how a given repo and and a given ticket are related to each other

Feneas forum thread

Tickets, issues, project management etc. are a concept distinct from repositories (repos are just versioned file storage, basically). But these 2 things meet, when you wish you open a ticket on a specific repo. And the question is, how does ForgeFed software decide where to send the ticket? Possible examples: - No ActivityPub way to send the ticket; maybe just email the repo's maintainer - Send the ticket to the repo maintainer `Person` actor - Send the ticket to the repo team of collaborators - Send the ticket to the `Repository` actor, which perhaps manages tickets in addition to the actual VCS repo - Send the ticket to *another* `Repository` actor, which may be a repo containing the tickets, a-la distributed bug tracker such as *git-bug* or *Bugs Everywhere* - Send the ticket to a separate ticket tracker which manages tickets for the repo, and that tracker may be entirely separate software on a separate website Question: When I have a bug or feature request to submit against a specific repo, how does my client software know where to deliver it? How can it choose among all those options above? We need to decide how it's done because there's no obvious way: - Gitolite, Gitosis, cgit, gitweb... manage only repos, not tickets - githu8, gitlab, Gogs, Gitea... manage tickets per-repo - Some projects have a dedicated fake empty repo used just for tickets - Some projects use an external bug tracker such as Bugzilla or Redmine or Trac or Taiga etc. - Some projects just say "email bugs to maintainer" - Some software supports a variety of project management features including ticket tracking and VCS repos, but neither is a primary feature/object and it's not automatically obvious how a given repo and and a given ticket are related to each other [Feneas forum thread](https://talk.feneas.org/t/determine-where-to-send-tickets/178)
zPlus commented 4 months ago
Owner

The thing that makes most sense to me is simply to send a new ticket to a Repository. Somebody/Something that is in charge of reading the Repository INBOX will decide what to do with the messages.

For example what I do on MCFI is:

  1. a Person sends an Offer(Ticket) activity to a repository
  2. the Repository doesn't do anything
  3. MCFI, that is in charge of automatically reading a Repository's INBOX, finds the Offer and automatically accepts it, so it sends an Accept activity to the Repository's followers. By contrast, MCFI ignores users completely, because I'm using CLIFF as a local client to manage my own IN/OUTBOX

If you replace MCFI with anything else, for example bugzilla or trac or taiga, if they speak ActivityPub they can simply connect to the Repository using C2S and do whatever they want with the INBOX messages. If nobody reads a Repository INBOX, or nobody replies to Tickets, they are ignored. On the other hand, somebody could take on responsibility for multiple Repositories (perhaps discovered from a Project actor?). I could use something akin to CLIFF for managing my Repository inbox locally but I just preferred to accept everything automatically instead of waiting for my manual input.

A possible example with gitolite+cgit+bugzilla:

  • all text/html requests are handled by default by cgit, which displays repositories
  • repositories clone/push are handled by gitolite over ssh or smart http
  • all application/activity+json requests are handled by an activitypub server that understands forgefed
  • bugzilla can be on an entirely different domain (or the same domain) and reads the repository INBOX as well as write to its OUTBOX if required
The thing that makes most sense to me is simply to send a new ticket to a Repository. Somebody/Something that is in charge of reading the Repository INBOX will decide what to do with the messages. For example what I do on MCFI is: 1. a Person sends an Offer(Ticket) activity to a repository 2. the Repository doesn't do anything 3. MCFI, that is in charge of automatically reading a Repository's INBOX, finds the Offer and automatically accepts it, so it sends an Accept activity to the Repository's followers. By contrast, MCFI ignores users completely, because I'm using CLIFF as a local client to manage my own IN/OUTBOX If you replace MCFI with anything else, for example bugzilla or trac or taiga, if they speak ActivityPub they can simply connect to the Repository using C2S and do whatever they want with the INBOX messages. If nobody reads a Repository INBOX, or nobody replies to Tickets, they are ignored. On the other hand, somebody could take on responsibility for multiple Repositories (perhaps discovered from a `Project` actor?). I could use something akin to CLIFF for managing my Repository inbox locally but I just preferred to accept everything automatically instead of waiting for my manual input. A possible example with gitolite+cgit+bugzilla: - all text/html requests are handled by default by cgit, which displays repositories - repositories clone/push are handled by gitolite over ssh or smart http - all application/activity+json requests are handled by an activitypub server that understands forgefed - bugzilla can be on an entirely different domain (or the same domain) and reads the repository INBOX as well as write to its OUTBOX if required
zPlus commented 4 months ago
Owner

Basically, the idea is that a Repository works as a mailbox for a specific repository. There could be 10 different clients reading the same inbox, everyone managing some Activities and ignoring others. If it makes sense.

Basically, the idea is that a `Repository` works as a mailbox for a specific repository. There could be 10 different clients reading the same inbox, everyone managing some Activities and ignoring others. If it makes sense.
fr33domlover commented 3 months ago
Collaborator

That makes sense, but it kind of abuses the C2S API for communication between servers (buzgilla having access to the repo's outbox), and it only works when you have a separate ActivityPub server component that understands and handles all of ForgeFed. That's fine, but imagine this: What if I wanted to make an ActivityPub component for Gitolite, that just handles repo manipulation and doesn't do anything else? If I wanted to do that, it would save tons of work to be able to handle only the VCS related stuff, and not implement anything related to tickets.

The scenario where different components are different actors is a scenario we need to take into account anyway, since the actor model allows for that; if we also had a bugzilla-has-access-to-repo-actor scenario, now that's 2 different situations that people's would need to be ready for.

My proposal: Provide a general purpose solution that doesn't rely on servers having access to each other via C2S (because at the core, federation is just S2S, that's the tool we're modeling for, using C2S or anything else for communication between servers is out-of-band), and if people want to implement things the way your gitolite+cgit+bugzilla example says, they can. It just wouldn't be the only way to do it.

Suggestion: Have a property ticketsTrackedBy, which allows an object to state who tracks its tickets. If people want to implement stuff the way your example says, or their software is a forge where repos handle their tickets, then they set ticketsTrackedBy to the repo URL itself. And if people want to refer to an external issue tracker, separate actor, hosted locally or remotely, they can.

What do you think?

My proposal doesn't conflict with yours, it just adds the ability to defer ticket tracking to a different actor, so that people can implement components without out-of-band access if they wish (just plain S2S).

(Little side note: In the pure actor model perspective, the repo actor is a machine-controlled entity, it manages its own outbox and inbox, nobody else posts into its outbox just like nobody posts into your Mastodon outbox except for you and anything else would be impersonation)

(Another side note: It's perfectly possible to have a ForgeFed component that talks to bugzilla, gitolite etc. behind the scenes and they can be on different domains etc., I just don't want that setup to be the only possible setup, I'd like implementations to be free to split and delegate things)

That makes sense, but it kind of abuses the C2S API for communication between servers (buzgilla having access to the repo's outbox), and it only works when you have a separate ActivityPub server component that understands and handles all of ForgeFed. That's fine, but imagine this: What if I wanted to make an ActivityPub component for Gitolite, that just handles repo manipulation and doesn't do anything else? If I wanted to do that, it would save tons of work to be able to handle only the VCS related stuff, and not implement anything related to tickets. The scenario where different components are different actors is a scenario we need to take into account anyway, since the actor model allows for that; if we also had a bugzilla-has-access-to-repo-actor scenario, now that's 2 different situations that people's would need to be ready for. My proposal: Provide a general purpose solution that doesn't rely on servers having access to each other via C2S (because at the core, federation is just S2S, that's the tool we're modeling for, using C2S or anything else for communication between servers is out-of-band), and if people want to implement things the way your gitolite+cgit+bugzilla example says, they can. It just wouldn't be the only way to do it. Suggestion: Have a property `ticketsTrackedBy`, which allows an object to state who tracks its tickets. If people want to implement stuff the way your example says, or their software is a forge where repos handle their tickets, then they set `ticketsTrackedBy` to the repo URL itself. And if people want to refer to an external issue tracker, separate actor, hosted locally or remotely, they can. What do you think? My proposal doesn't conflict with yours, it just adds the ability to defer ticket tracking to a different actor, so that people can implement components without out-of-band access if they wish (just plain S2S). *(Little side note: In the pure actor model perspective, the repo actor is a machine-controlled entity, it manages its own outbox and inbox, nobody else posts into its outbox just like nobody posts into your Mastodon outbox except for you and anything else would be impersonation)* *(Another side note: It's perfectly possible to have a ForgeFed component that talks to bugzilla, gitolite etc. behind the scenes and they can be on different domains etc., I just don't want that setup to be the only possible setup, I'd like implementations to be free to split and delegate things)*
zPlus commented 3 months ago
Owner

When I raised this issue my understanding was that there would have always been a Repository actor and that collaboration developed around a repository. Like here on NAB for example you don't have an issue page or a wiki without creating a repository first, every tool is in function of the repository. But the actual assumption in forgefed is that a repository doesn't not have to exist, because it's meant to federate project collaboration in general whether a repository exists or not. So I've actually changed my mind and I accept your solution of defining multiple actor types as the better solution.

So the problem is that if one just want to follow a project, he needs to hunt down all the actors involved. In Vervis as well as in MCFI we can have only one actor acting as Repository+IssueTracker, which means there's only one URL. Other projects may use different software that only implements one actor.

For the first version of forgefed we could simply leave it as that, that is people add a list of actors in their project README and others will follow them manually. It will be the same way that mailing lists or rss already work: a project can have several mailing lists or rss feeds and you subscribe to them one at a time. Then maybe we can devise a more intelligent discoverability feature in future revisions if there is demand for it.

When I raised this issue my understanding was that there would have always been a `Repository` actor and that collaboration developed around a repository. Like here on NAB for example you don't have an issue page or a wiki without creating a repository first, every tool is in function of the repository. But the actual assumption in forgefed is that a repository doesn't not have to exist, because it's meant to federate project collaboration in general whether a repository exists or not. So I've actually changed my mind and I accept your solution of defining multiple actor types as the better solution. So the problem is that if one just want to follow a project, he needs to hunt down all the actors involved. In Vervis as well as in MCFI we can have only one actor acting as Repository+IssueTracker, which means there's only one URL. Other projects may use different software that only implements one actor. For the first version of forgefed we could simply leave it as that, that is people add a list of actors in their project README and others will follow them manually. It will be the same way that mailing lists or rss already work: a project can have several mailing lists or rss feeds and you subscribe to them one at a time. Then maybe we can devise a more intelligent discoverability feature in future revisions if there is demand for it.
fr33domlover commented 3 months ago
Collaborator

if one just want to follow a project, he needs to hunt down all the actors involved.

Hmmm let's see. I agree, we don't want that to be a problem. But perhaps there is a simple solution to this. I'll try to gather thoughts:

  1. Since repos will point to their ticket tracker and other components etc., a ForgeFed client can automatically gather those objects and follow all of them in 1 click
  2. Inbox forwarding: If you follow a repo, and you also want to be notified on tickets related to this repo, you will be notified: Activities that open/close/edit/comment on tickets related to the repo will list the repo's followers as recipients (in the "to" or "cc" fields). The repo actor will then perform standard ActivityPub inbox forwarding: It will detect that the ticket is related to it, and will forward the activity to its followers, i.e. to you.

How does this sound? I think it solves the problem ^_^

It doesn't get mentioned yet in our spec because it's a C2S requirement: When you submit a ticket related to a specific repo, list the repo's followers as recipients. Alternatively, as a fallback for safety, we can have the Repository actor follow the ticket tracker actor, and simply send Announce activities that link to the stuff happening in the ticket tracker. So we also have a safe server-side fallback.

> if one just want to follow a project, he needs to hunt down all the actors involved. Hmmm let's see. I agree, we don't want that to be a problem. But perhaps there is a simple solution to this. I'll try to gather thoughts: 1. Since repos will point to their ticket tracker and other components etc., a ForgeFed client can automatically gather those objects and follow all of them in 1 click 2. Inbox forwarding: If you follow a repo, and you also want to be notified on tickets related to this repo, you will be notified: Activities that open/close/edit/comment on tickets related to the repo will list the repo's followers as recipients (in the "to" or "cc" fields). The repo actor will then perform standard ActivityPub inbox forwarding: It will detect that the ticket is related to it, and will forward the activity to its followers, i.e. to you. How does this sound? I think it solves the problem ^_^ It doesn't get mentioned yet in our spec because it's a C2S requirement: When you submit a ticket related to a specific repo, list the repo's followers as recipients. Alternatively, as a fallback for safety, we can have the Repository actor follow the ticket tracker actor, and simply send `Announce` activities that link to the stuff happening in the ticket tracker. So we also have a safe server-side fallback.
fr33domlover commented 2 months ago
Collaborator

Here's what I'm going to document in the spec for Draft 1. Please comment if you have objections.

There will be bidirectional reference between the repo and the ticket tracker, and implementations SHOULD verify this when they open a ticket. It's bidirectional to prevent a situation where repos or other objects maliciously or accidentally point at some issue tracker and it then causes lots of spam or unrelated tickets that need to be manually moved/deleted. Anyway, it's easy to remove this requirement later.

There will be a property ticketsTrackedBy, which an object use to state which actor is responsible for tracking its work/tickets/issues/bugs. And there will be tracksTicketsFor, which a ticket-tracking object can use to state for which objects it agrees to track tickets.

When you're ready to open an issue on a repo R and it says ticketsTrackedBy some tracker T, you make sure that T tracksTicketsFor R. If that's the case, you proceed to send the ticket to T, probably mentioning R in some way.

Here's what I'm going to document in the spec for *Draft 1*. Please comment if you have objections. There will be bidirectional reference between the repo and the ticket tracker, and implementations SHOULD verify this when they open a ticket. It's bidirectional to prevent a situation where repos or other objects maliciously or accidentally point at some issue tracker and it then causes lots of spam or unrelated tickets that need to be manually moved/deleted. Anyway, it's easy to remove this requirement later. There will be a property `ticketsTrackedBy`, which an object use to state which actor is responsible for tracking its work/tickets/issues/bugs. And there will be `tracksTicketsFor`, which a ticket-tracking object can use to state for which objects it agrees to track tickets. When you're ready to open an issue on a repo R and it says `ticketsTrackedBy` some tracker T, you make sure that T `tracksTicketsFor` R. If that's the case, you proceed to send the ticket to T, probably mentioning R in some way.
fr33domlover commented 2 months ago
Collaborator

I documented the above in the spec; leaving this issue open for finalizing later; removing from Draft 1 as the method above is enough for now.

I documented the above in the spec; leaving this issue open for finalizing later; removing from *Draft 1* as the method above is enough for now.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.