BlenderBIM is getting bigger and bigger, what about using it's own repo?

[Amoki]

BlenderBIM is becoming a very nice software, with many collaborators and functionalities. This implies a lot of PR, issues, discussions, and releases.
I'm not a BlenderBIM user, just an IfcOpenShell user and it's becoming hard to follow IfcOpenShell evolution because GitHub can't allow me to filter notifications by tag. If I want to follow IfcOpenShell, I must follow BlenderBIM. I have the same issue if I want to read the latest commits to see bug fixes and improvements or check the latest release.
A simple button name change could imply an issue, a commit, a PR, a release, and 3 GitHub notifications.

If I understand well, BlenderBIM comes with its own IfcOpenShell build embedded and doesn't depend on IfcOpenShell source code directly.
Many people have write permission to the entire repo and are asked not to touch anything outside the BlenderBIM directory, but GitHub can't restrict them.

Using the IfcOpenShell repo is convenient for small projects. It gives a space with helpful people, simplifies hosting, upgrades management, and visibility. When the project gets bigger, these benefits become less significant. BlenderBIM has its own website, releases, and maintainers.

What do you think about moving the folder src/blenderbim to its own repository?

[Moult]

The BlenderBIM Add-on source code is decoupled from the C++, but most of the functionality is part of the IfcOpenShell Python module, especially the API module which is how everything in the BlenderBIM Add-on gets executed - the Blender-related code is a GUI and UX layer syncing, primarily. In addition, the code for IfcDiff, IfcPatch, IfcP6 (+MSProject), etc are all Blender agnostic, yet is closely synced to a UI within Blender. In short, the BlenderBIM Add-on code is only half Blender - the other half is agnostic, and outside the src/blenderbim directory.

I understand the noise when following :( I personally wouldn't want to split the repos, though, with the primary reason being that development really is split halfway (the ifcopenshell.api namespace is the biggest aspect).

Curious on what others think.

[aothms]

I think this is something debated a lot in the monorepo vs. submodules discussions. From what I understand most companies these days gravitate towards monorepos. But I must admit I don't know how notifications are handled in that sense. I also don't really use notifications personally. Tagging would probably be pretty inconsistent anyway so I'm not sure that is a real solution to combat the noise.

It wouldn't really apply to BlenderBIM only I think though although it is probably most "disruptive" on the notification stream. As Dion has noted, actually a lot of BlenderBIM work is actually work on the API. In the very near future we're going to ramp the work on drawing generation essentially causing BlenderBIM and IfcConvert (as a library) to become better friends.

I can imagine other projects would have opted for more granular project structure (e.g C++parser C++geometry PythonAPI PythonUtils Contrib etc.) but it brings its own set of problems in keeping things consistent. I think it'd have to be pretty granular to make sure that all notifications are meaningful.

I think the only real solution is to have a proper forum with a good hierarchy of topics that you can subscribe to and maybe a better bug tracking system. Using git log it's already possible btw to filter activity on specific items in the tree, also the github web interface allows that e.g https://github.com/IfcOpenShell/IfcOpenShell/commits/v0.6.0/src/ifcparse

On a side note, people are never asked to only touch specific folders. On the contrary, everyday I hope more people will touch the C++ parts :)

[Amoki]

Companies tend to use mono-repos, but some big FOSS projects like Ansible split their repos recently. Companies use internal tools to manage issues (eg: Jira) when FOSS heavily uses GitHub and it's quickly limited (thousands of issues for big projects).

I wanted to say that only the life cycle product management of BlenderBIM should be moved: specific issues to BlenderBIM UI, blender plugin build, releases. BlenderBIM team added many independent features to IfcOpenShell and it's awesome!

Using a repo like IfcOpenShell/BlenderBIM won't dissociate it from IfcOpenShell too much, I think collaborators won't be confused too much as the UI is in its own folder while the core code is somewhere else already.

It may be less straightforward for developers if they need to synchronize 2 repos to develop a feature though. I don't know how it currently works.

[Moult]

Disassociation isn't the concern, it's the development which would need to sync 2 repos to develop a feature, like this commit which just came through.

One option is to split the issue tracker? Or change issue tracker?

[Amoki]

A different issue tracker could mitigate the problem, yes!

[htlcnn]

For the BlenderBIM daily builds, I think they could be moved to a forked repo similar to IfcOpenBot so they wouldn't spam IfcOpenShell's followers who only want to track IfcOpenShell related issues/builds

[aothms]

@htlcnn I think that's a good idea. I can create a repo and create a secret. It seems like it requires a little bit of configuration to push to another repo's releases. https://stackoverflow.com/questions/61426487/github-actions-release-to-other-repo

[Moult]

https://community.osarch.org/discussion/1645/ifcopenshell-project-and-repo-structure-modernise-split-up-clean-up

[Moult]

Closing as the conclusion is that we're not splitting the repos, and all the actions discussed in the forum thread have also been implemented.