Closed rpdelaney closed 10 years ago
I'm officially not a fan of doing submodules for this--I'd prefer larger centralization. Ideally, since EQ + Promod + other configs will all be living on the same servers together without conflicts, I'd rather work towards having a single repo that consolidates them all so conflicts can be resolved during development rather than during installation.
Could you amplify on "larger centralization" -- are you suggesting that Promod and EQ should both be developed in a single repository?
Yes, that's what I'm suggesting. I don't see a major downside to the centralization. It seems to me that any conflicts between the two configs are conflicts that will arise in the production environment anyway (since servers run both configs), so dealing with those conflicts in one single development environment seems way more efficient than dealing with them in the field.
(That was also what the point of the LGOFNOC/Confogl3 setup was supposed to be)
All right. It does leave an unresolved question about what happens with forked configs that want to be compatible with promod -- we would be making their job harder by forcing them to continue to merge from upstream and sort through the history as the plugins are added, removed, updated, etc. Also, any scenario where a promod fork was abandoned and required old plugins (witchparty) would make a mess. Submodules provide neat solutions to all these issues.
However, based on prior experience, perhaps we can be pessimistic that any hypothetical fork would use git at all...
It would be fair to say that submodules are closer to theoretical "correctness" but that the real-world ROI is easy to over-estimate. :-) /jargon
we would be making their job harder by forcing them to continue to merge from upstream and sort through the history as the plugins are added, removed, updated, etc.
Don't they have to do this anyway? They just do it from outside, via binaries. And they could still choose to operate in the same way if they want.
You're right. It's not an argument against merging Promod and EQ development into a single repo -- it would make little or no difference to developing a fork. However, the issue I'm raising in this thread is whether plugins that Promod (or EQ) (or any other config, for that matter) depends on should be installed as submodules. That does make a difference to a developer of this hypothetical fork.
Ah, sorry, I misunderstood your comment.
How exactly would you propose we split up the repo into submodules then? What I'm fearing is the bouncing around of plugins between different repos. Shared plugins vs forked plugins. Specifically, moving forked ones to be shared sounds quite difficult.
As I'm reading you, you asked two questions:
A repo for every single plugin? Seriously? Let's be realistic, is this really necessary or practical, at this point? 95% of these plugins' source code will never be touched again. Why bother?
On the one hand, I see where you're coming from. On the other, I'm thinking "Oh yes, just think of all those precious repositories that won't have to be wasted!" :smile: They're not precious resources -- and I'll create them if that seems tedious. Anyway, it's not any kind of big deal so I'll leave it there.
@Attano, in #2 @ProdigySim suggested that using git submodules for the individual plugins is worth considering. I agree.
Advantages:
Disadvantages:
[1]: Having a build script is probably a good idea anyway, per prior discussion also in #2.
Thoughts on this?