Closed tehKaiN closed 1 year ago
when I work with something new and it's included as a part of repo with a working example than it's much easier for me to start experimenting with it and get familiar looking at separate repos is always a hussle for me, and following instructions on combining things is not easy for me as I don't program on a daily basis anymore.
I prefer if it's all combined even if there are LIMITATIONS. If I need something for my game and I have a working example of something that is not yet finished it's still a big help and a motivation to help the author with further work.
It's a psyhical barrier for me to download and try a separate repo that is not yet finished, if you know what I mean. I prefer to help somebody than do develop my own solution from scratch if I need it for my current project. Having all that in one place with a documented limitations and cautions is my personal preference
I like the idea of having more things available. But it's a maintenance burden to shoulder. Regarding the performance cost of abstraction, the way I see that since ACE breaks compatibility once in a while anyway, for a specific game I would just modify the ACE code for that game if it needs the extra performance. Sure, it makes the ACE in the game diverge from mainline, but after some development on ACE master, it won't be compatible anymore either.
related to #74
If we zoom out enough we can see following things: discoverability, maintenance and compatibility. I think that ideal solution would be to keep great discoverability, keep the lowest ACE maintenance and compatibility moved from the shoulders of ACE.
In discoverability/maintenance we have de-facto following choices:
In compatibility I see few remarks:
From my side, I'm in favor of option 4. Proper instructions for extension developers would keep extensions as easy as single git submodule add
, keeping automated extensions list based on GitHub's tags and have it well displayed in ACE docs, would be a sweet spot for all mentioned cases and for all three parties: ACE, extension developers, extension users.
Another idea. I've thought about whether some of ACE parts shouldn't be considered extensions.
so to determine which parts are core and which aren't I've answered following questions:
Now if I try to answer those questions for ACE extensions mentioned earlier:
For other stuff, I'll let others do the self-assessment of their code if that's the approach we choose to follow. Extra questions which were answered in assessments above:
Could such assesments be helpful on determining if those things are core or should be kept separately as extensions? Should we go through such checklist for each pull request with new code?
Bump. Personally I think refining such self-assessments is the way to go to determine whether stuff goes into main repo, but I would like to hear some more opinions if the idea is solid.
Have you thought about having a contribution, contrib, section where it has these not core but user contributions? Then it is still optional but supported by ACE?
This doesn't work for my AGA stuff since it deals with to many internal systems. But it would be an interesting idea.
Get BlueMail for Android
On 2 May 2023, 6:24 pm, at 6:24 pm, KaiN @.***> wrote:
Bump. Personally I think refining such self-assessments is the way to go to determine whether stuff goes into main repo, but I would like to hear some more opinions if the idea is solid.
-- Reply to this email directly or view it on GitHub: https://github.com/AmigaPorts/ACE/issues/189#issuecomment-1531073601 You are receiving this because you are subscribed to this thread.
Message ID: @.***>
What I'm afraid of with having a contrib folder inside main repo, is that I and other maintainers will have to support that code and make sure that it builds and works with every PR and internal ACE changes. This may be fine at first when there's not a lot of it but then it could pile up to quite a burden and may even require total rewrite of one or ten contrib modules when refactoring parts of ACE. If we assume that the person who added something to contrib folder must keep it up to date with separate PRs, I fear that in time some things will rot away and repo will be cluttered with broken code. What I'd like to do is to keep the contents of repo neat and tidy, moving the effort of maintaining "optional enough" stuff to other people.
If we go the way of contrib stuff in separate repo, then yeah, some unified structure would have to be conceived, so that one can call contrib stuff with #include <ace/contrib/foo.h>
or something like that.
Time to make some decisions.
I think we could give the whole thing the benefit of the doubt and see what happens when we accept all contributions unless they don't fit into core engine significantly.
What does significantly mean in this context? Dunno really. I'll try to do some kind of contribution guidelines based on discussion above and self-assessment PR template. Regarding my code, I'll create PRs with audio mixing and bob systems soon and see if anyone opposes.
I've adapted Jeroen Knoester's audio mixer for ACE's use as a standalone manager (currently available on Aminer repo on separate branch), but I have some doubts if I should incorporate it into ACE:
on the other hand, there are counterarguments:
on even other hand, there are some features proposed by other ppl (Kwahu's voxel renderer, generic entity-component system) which I'm not sure if should be added because:
For the same reason I'm holding back from adding my bob system - my first thought was to release few titles using it to be sure that it fits many usage scenarios, but perhaps that too should be separate package.
Also, I'm afraid that as those extra packages get incorporated, incompatibilities between them may arise, forcing me to make sure that everything works in any configuration, perhaps sacrificing speed for compatibility.
What do you, as ACE users, think of it? What rules should be used to determine if feature should be added to ACE? Should ACE itself be tiny bare-bones framework/environment or a Swiss army knife?