Does adding a supported forge (e.g gitlab instance) considered a possible save now request?

That would be great.

In T336#21431, @ardumont wrote:

Does adding a supported forge (e.g gitlab instance) considered a possible save now request?

Yeah, that would be cool. Nice idea.

We certainly want to allow users to suggest saving instances of forges we already support (e.g., GitLab). And reusing the same interface and moderation process for save origin now totally makes sense.

I'm not sure how easy it would be, because the underlying backends are quite different. E.g., you don't "schedule" the addition of an entire forge as a single task, so the monitoring would be different. But there are certainly some pieces, at least at the UI level, that we might want to reuse.

@anlambert maybe think about this additional use case and how it might fit in, but let's not block the save origin now work due to this.

E.g., you don't "schedule" the addition of an entire forge as a single task,

Yes, there are 2 tasks for now (incremental, full) but if we also hide that detail within T1157... Then that could be a win, i think ;)

In T336#21437, @ardumont wrote:

E.g., you don't "schedule" the addition of an entire forge as a single task,

Yes, there are 2 tasks for now (incremental, full) but if we also hide that detail within T1157... Then that could be a win, i think ;)

But that's listing, not loading. It's not clear to me that a user that added a forge would be interested in knowing when we're done adding its origins, that's just an implementation detail. The user will want to know when we have archived all of it at least once, which is complicated to define. It might be enough to give visibility to when the listing is done, but it'll certainly require a different user-facing explanation than saving an origin.

But that's listing, not loading. It's not clear to me that a user that added a forge would be interested in knowing when we're done adding its origins, that's just an implementation detail. The user will want to know when we have archived all of it at least once, which is complicated to define. It might be enough to give visibility to when the listing is done, but it'll certainly require a different user-facing explanation than saving an origin.

If we implement this today, we should be clear from the start that we can answer the user only the 'done listing?' question (for now).

And then iterate to improve on this.
Ultimately, implementing the missing tool (cross-referencing lister's db, scheduler, archive) which will be able to answer the real important one ('done ingesting?').

require a different user-facing explanation than saving an origin.

Nitpicking here, it's not just saving origins, it's also the scheduling of each origin ingestion (without this, it's pointless indeed).

Cheers,

this is now done (YAY :-)), closing the task to reflect current status