Doesn’t appear in Google search and so is difficult for potential contributors to find
The last commit was in 2023
It’s impossible to tell if pull requests will be accepted once the author is no longer active on the project
Doesn’t have all of the changes from the parent Github or sourceforge repositories.
Given all this, I’ll probably go with ghaerr/agg-2.6.
Later, I’ll need to figure out whether to just copies the files from the Github repository into our agg folder or use something more fancy like submodules.
So far, it’s not looking too bad. There’s been surprising little breakage. A commit changing const to non-const parameters has caused some breakage so far. Probably it would be best to just revert it.
I’ve done a little checking on this so far. It seems some of the changes we’ve made are also present upstream. I’ll still need to figure out if all of our changes have been moved over and what to do with those that haven’t been.
Edit: Yes, there are some changes that we’ve made that need to be carried over.
I don’t think we should go with any of these. None of them looks like a suitable “upstream” for us to work with; even the one from 2023 isn’t very active.
Furthermore, don’t a number of them miss patches from each other? This also ignores third-party repositories with AGG and their own modifications thereto, of which I know of a few and have them bookmarked somewhere.
IMHO we should not try to upgrade AGG before really evaluating all the different repositories.
If there are features we need to import, we can do that.
I only need some features added to the agg_trans_perspective.h. Simply replacing the current version of that file with a newer version should work.
Though by now I am close to having the newer version imported with all of our changes applied on top. The commit would look something like this commit. So maybe just continue? Though I’m not sure yet how much breakage that would cause and how much time it would take to address it.
Yes, breakage is possible; AGG changes have the potential to cause app_server crashes (many of our fixes are related to that, in fact.)
Due to there being no single definitive “upstream”, I would argue to hold off on any big changes like that, until that problem is sorted out. Or we create our own “vendored” repository, forked from another or started from scratch, and apply our own patches on that before merging anything into the tree…
If you just need a newer copy of one file, that’s easier and we should just do that for the time being, I’d say.
Not being very active is normal. Agg is a mature piece of software, besides the occasional bugfixes and new feature, it does not need much. In fact, in this situation I prefer a repository with not many changes than one with a “let’s rewrite everything” approach.
Having our changes merged with one of the repositories (doesn’t matter which one) is one step towards reducing the number of different implementations. Being able to say “we use this specific version from this repository” will reduce the work in studying what else we could merge.
Then there is the question of how to integrate it in Haiku. Normally we wouldp package it at haikuports and make the haiku build use the resulting prebuilt package. Since the picked repository is a bit “uncertain” for now (it is one of several forks of the library, and we don’t know if it will continue to be maintained), we can keep our copy of it in-tree for now, while also making sure that our changes are in that other repo as well. To me this seems better than doing our own vendored fork, oven if not as good as ressurecting the original sourceforge project.
That would be the way for Haiku to have its own fork of AGG, get what matters from the 3 patches and improvements repositories, apply solutions and patches that meet Haiku’s needs!
At first, PulkoMandy’s idea of a fork and its own AGG repository for Haiku was the best solution.
AGG repository from svn, commits stopped in 2021, hardly accepted, the same goes for AGG repository with commits from 2022, maybe AGG repository with 2023 accepted, but I opened an issue, I didn’t even get a response!
I don’t know why you put this idea in my mouth, it is the opposite of what I said. We should try as much as possible to get our changes into one (or more) of the existing forks if possible. Not make and maintain yet another fork…
My suggestion would be to contribute to 3 repositories and see which one is more receptive to contributions, but I believe a repository with commits from 2023 is more receptive to contributions.
I fear this approach would cause merge conflicts if both an upstream and a downstream repository accept the same change and then the downstream tries to merge changes from upstream. Though, the file will have changed the same way across both, so, maybe not?
I’m thinking of sending the change to ghaerr/agg-2.6, seeing if they’re responsive, and then submitting to aggeom/agg-2.6 if they’re not.
It seems fine to send the changes to all repositories (and cross-link your merge requests so people are aware of it). And see what happens from there.
If the same change is merged in two different places, Git should have no problem with that. And by submitting our changes to all places, we will have done our best effort to bringing things closer to reunification?
By now, the perspective transformation can be saved. I may decide to modify the saving behaviour a bit, but it’s close. The transformation can detect invalid transformations and can deal with them gracefully. I still need to get undoing/redoing to work.
This is clearly the hardest thing that I’ve worked on in GSOC so far. I’ve been working on it for over 6 weeks by now and it’s clear that it will take at least one more week before it’s done!
SVN repository has fixes [138], the 2 github repositories have up to [132] with their own changes. Repository ghaerr/agg-2.6 has PRs with improvements stopped in time, for this reason the fork aggeom/agg-2.6 was created, the fork creator explains the reason in the PR of the Conan repository!
Ah, finally I understand why you recommended aggeom/agg-2.6 .
I favored ghaerr/agg-2.6 partly because I saw that there were three closed PRs, two of which are newer than the PRs that haven’t been accepted yet. One of the PRs which haven’t been accepted yet has some unaddressed reviews. But I don’t see any reason for the other open PR not to have been accepted yet, so, that’s somewhat concerning.
It’ll be interesting to see how the two Github repositories react to my changes.
And the winner is… of all things… the Sourceforge repository . Jim Barry finally woke up and closed 4 tickets (Sourceforge’s pull requests). Only one remains. I closed the pull requests to the two GitHub repositories. Think it’s time to start upstreaming all of our changes?
.
).
. Jim Barry finally woke up and closed 4 tickets (Sourceforge’s pull requests). Only one remains. I closed the pull requests to the two GitHub repositories. Think it’s time to start upstreaming all of our changes?