Should farmOS repositories be merged?

A few thoughts around the "advantages" listed above...

Regarding:

Each component has it's own issue queue.

In a combined-repo approach, this could be simulated using the "Component" dropdown that drupal.org issue queues provide.

Regarding:

You can include individual modules in other Drupal sites (that are not necessarily farmOS installation profiles).

I like this from the perspective of a Drupal developer - because it enforces a conceptual separation of concerns nicely.

It also makes it possible for OTHER Drupal distributions to be built using some of the same modules. (I'll add this to the list of advantages.)

But the question is: is the cost worth the benefit? Will anyone ever take advantage of that possibility?

If not, are we just making things harder for farmOS core development??

A few thoughts around the "disadvantages" listed above:

Regarding:

It is confusing to newcomers which project/repository a new issue should be filed under.

This is the biggest argument for merging the repositories together. It would be a lot easier for newcomers to approach if there was only one project / repository.

But on the other hand, perhaps some good documentation on the relationship between all the projects would resolve this issue - and would be a good thing to have regardless.

Regarding:

farmOS core maintainers need to move issues around to the proper queues.

Personally, I really don't mind doing this right now. And it provides an opportunity for all new requests/reports to go through an initial filtering process, and be added to the appropriate roadmap(s). But it is not necessarily scalable - if/when the rate of requests rises, it will become harder to keep up.

Another advantage of the current approach comes to mind (added to the description):

farmOS core has flexibility in deciding which modules should be included in core vs contrib

By this I mean: if we decide that it doesn't make sense for a module to be included with farmOS core, we can simply remove it from the makefile. It still exists as a separate project that people can choose to include themselves if they want. So removing it from the farmOS core distribution would not require moving code/issues - they are already in a separate repo.

Of course, removing modules should always be done carefully: if a module suddenly disappears in a farmOS update, it could cause issues on existing sites if they didn't know to download the module manually. There are ways to approach this, though (deprecating a module in one release, and adding warning messages that it will be removed in the next release). This is largely hypothetical, so it's not a huge concern at the moment.

Likewise, if a farmOS add-on module is created and develops into a mature and very useful contribution, the farmOS core team can decide to INCLUDE it in farmOS, simply by adding it to the makefile. The project can still remain separate, with it's own project page and issue queue.

Thanks Bruce! Eager to hear what can be improved!

I'm still leaning towards keeping them as separate repositories for now - but still giving it thought. I might move the Farm Theme project into the farmOS project - because out of all the various projects I think that is the least likely to be used outside of the farmOS distribution.

Also worth saying: if you are planning on rolling your own, I would probably recommend still starting with the farmOS distribution as your base, but making modifications from there. Then if the improvements make their way into farmOS core it's easier for you to "reset" to the core codebase, instead of maintaining your own. Lots of ways to go about it though!

I've been giving this a lot of thought and I am starting to lean towards including most of the farm_* modules in the main farmOS distribution repository. I DO NOT plan to do this in the 7.x-1.x branch of farmOS, but maybe in 8.x-2.x, which I am starting to break ground on.

I have heard from many folks in the community that having multiple separate repositories is confusing and poses a real roadblock to getting involved with the codebase. And having feature requests and bug reports spread out across multiple issue queues also makes things more complicated. It's sometimes hard to explain WHY a certain issue belongs in a certain queue, so I find myself telling people to just add the issues to the main farmOS queue and then I'll reorganize them. This isn't ideal for long-term maintenance and contributions.

In other words, I'm not sure the advantages outweigh the extra complexity for users and contributors.

Each piece will still be self-contained as separate modules within the distribution, so it would still possible to pull them out and use them separately if you really need to.

Just sharing my current thinking... curious to hear thoughts. :-)

I'm getting started on the 8.x-2.x branch. More details here: #2361735: [META] Map out Drupal 8 / farmOS 8.x-2.x Dependencies

I think it will be best to merge most of the farm_* modules into this repository, for the reasons listed above.

Closing this issue, but feel free to share thoughts.

OK, so after working with merged repositories in the 8.x-2.x, and then going back to the multi-repo approach in the 7.x-1.x branch, I'm REALLY feeling the urge to do this in both branches. It makes things so much easier.

Reopening this and changing the version to 7.x-1.x.

On second thought - I'm going to leave this discussion alone and start a new task for implementing it, because there are some details to figure out.

Here is the new issue: #2876992: Merge farmOS repositories into drupal.org/project/farm