# Pull request midway report <!-- In this report, the midway progress is discussed in regards of the contributions towards the libGDX project. Firstly, the pull requests that were made so far are discussed. After this, the plans for the remaining time of the course are discussed. --> In this report we discuss our progress towards contributing to libGDX. We first review the changes we submitted and then lay out some plans for future contributions. ## Pull requests made <!-- There are now 2 pull requests made. Both pull requests are mentioned now in more detail. --> We have submitted two pull requests to the main repository of libGDX. These are: ### Remove commented code <!--The first pull request that was made for the libGDX project, was a relatively simple one. The choice for a simple pull request to start with, was to get used to working with the fork of the libGDX repository and taking a first look at their codebase. This first pull request involved removing commented code, in order to make a few specific files more neat. This pull request can be found --> Our [first pull request](https://github.com/libgdx/libgdx/pull/6435) for the libGDX project was a relatively simple one. We decided to keep it simple so we could get used to the workflow of creating pull requests, that is: forking, making the modifications, submitting the PR and finally discussing the changes with the developers. The best candidate for a PR like this was removing commented code, something that is extremely unlikely to impact the behavior of the project but still has benefits for the project in terms of quality. We did discover that libGDX has legitimate instances of commented code. In order to streamline interfacing with native, non-Java code, the developers of libGDX have developed a preprocessor that uses C++ in comments in a Java class to generate the native implementation for the corresponding methods. We took care not to remove this. A maintainer quickly accepted and merged our pull request. A developer later commented that some of the commented code was sometimes useful, but another developer said that if it was useful, it should have been actual code guarded by a debug flag and not comments. ### Queue Testing and Quality improvement The [second pull request](https://github.com/libgdx/libgdx/pull/6444) aimed at improving the `Queue` datastructure class of the libGDX codebase. This involved cleaning up the file and writing tests for it, to assure that the file works as expected. Writing tests requires more intimate knowledge of the codebase, but involves less effort than implementing an entirely new function, which is a perfect candidate for the second pull requests. This PR raised a greater discussion than our first due to style issues. They have peculiar but strict style requirements, some of which their own autoformatter configuration does not apply correctly. Fixing this took some time. We have fixed this and are currently awaiting approval from the maintainers. ## Future plans For the remainder of this project, we have a few more plans: ### Improve and test more files On our issue board, we have taken note of more files that we would like to improve, like we did for the Queue class so far. These improvements include writing unit tests to confirm that the files do their job and to clean-up these files where this is possible. ### Update continuous integration Another point of improvement that we thought about, is that of improving the existing continuous integration of the libGDX project. Currently the test suite is not being called when running the pipeline. We believe that making execution of the test suite would be a good improvement, to make sure that other features will not misfunction when working on other features. There currently is a pull request open with a change to GitHub Actions, but it is a breaking update, so it might not be a good idea to update the existing CI pipeline. # Pull request final report <!-- Pull request final report: Again, ensure all submitted pull requests have been added to your DESOSA contributions listing. Furthermore, for work on potential pull requests you tried, but which eventually did not result in an actual pull request submission, write a short summary of what you did, and what was so hard about it.--> In this report we discuss the final progress toward contributing to libGDX. We first discuss the contributions we did since the midway report and then the contributions that we thought about, but did not end up doing. ## Further contributions done In addition to the contributions we added before the midway report, we also did more. We discuss this now. ### Writing more tests We worked on expanding the testbase for a few more classes. Tests were added for the following classes: - [Align](https://github.com/libgdx/libgdx/pull/6466) - [AtomicQueue](https://github.com/libgdx/libgdx/pull/6467) - [DataBuffer](https://github.com/libgdx/libgdx/pull/6468) - [FlushablePool](https://github.com/libgdx/libgdx/pull/6469) However, the pull requests take longer than expected to be merged. This was mostly due the fact that libGDX does not recognize the importance of testing in the slightest. Another problem was that their documentation style differs heavily from the typical Java style, which meant that we had to revert a lot of changes. ## Contributions that were not done We also considered some contributions that we, in the end, did not do. ### Continuous integration As mentioned prior, we contemplated helping libGDX with setting up a continuous integration pipeline. The situation since then did not change and we decided to put our effort elsewhere, because we did not want to disrupt their continuing efforts. After the main changes were merged, the maintainers moved on to fixing other parts of the pipeline and this did not leave much room for our changes.