Patrik Oldsberg

> Amazing proposal! I really like how it encapsulates much of the same pattern from the frontend system which provides integrators the same familiar interface and a consistent configuration experience...

Implementation is underway, tracked through a meta issue at https://github.com/backstage/backstage/issues/13081

@cowboyd other than for local development we didn't (seriously) consider any kind of system for hot-swappable plugins or anything like that. I don't agree that most mature plugin systems have...

Yep we'll have a look at local development more properly before settling things and happy to bounce ideas in that area too. We did some early experiments where we concluded...

Yep this doesn't seem like we're doing enough checks to highlight conflicts. I'll retitle the issue to focus on that. On a separate note, are you managing documentation versions through...

I think the way forward here is to add a check at [this](https://github.com/backstage/backstage/blob/5b830da1b13a6318626763f7632096d37d08da16/plugins/catalog-backend/src/service/DefaultLocationService.ts#L130) point to see if any of the resulting entities already exists in the catalog. We'd probably want...

Just to double check, is this with or without the new catalog and UrlReader improvements that enables ETag caching of requests towards GitHub?

Would this be using multiple plain registered `url` locations rather than `github-discovery` or a url with a wildcard pattern or anything like that? I think using a single URL with...

Yep definitely! You'd need to stick to something a bit more strict most likely, perhaps plain `catalog-info.yaml`, `*-info.yaml` and any other pattern :grin: Should note ofc that this is another...

@kuangp yep sorry, on my radar! It's a big one so needs a bigger chunk of time, which I haven't sliced out just yet 😅