raspberrypi-ui / wayfire

2 stars 2 forks source link

request to add piOS bookworm branch #10

Closed theofficialgman closed 5 months ago

theofficialgman commented 5 months ago

As indicated by the developer @spl237 , the master branch (the default branch in this repo) is allegedly not the version of the code shipped in piOS bookworm (https://github.com/raspberrypi-ui/wayfire/issues/8#issuecomment-2041875673)

The master branch is the only non-stale branch available on this repo. All other branches have not had pushes in 5+ months. However, piOS bookworm has had updates to its custom wayfire package as recently as 2 weeks ago (eg: https://archive.raspberrypi.org/debian/pool/main/w/wayfire/wayfire_0.7.5-1~bpo11+1~rpt34_amd64.deb).

image

I am requesting that this repository be updated with whatever the changes are being shipped in piOS bookworm that include the optimizations (as referred to here https://github.com/raspberrypi-ui/wayfire/issues/8#issuecomment-1951155629) in an appropriate branch since it appears that no such branch exists with that code.

CC: @botspot

spl237 commented 5 months ago

The repository is already fully up to date.

The fact that a branch is "stale" does not indicate that code in it is not used in the release, and I have no idea why you would even assume that. It is common practice to merge patches from multiple branches for release.

If you had bothered to look at the source for the package which is available from apt, you would see that the relevant patches with optimisations are labelled with references to commits in this repo so that it is obvious whence they came.

You appear to be attempting to prove that I am either mistaken or simply lying about the difficulty of merging our changes with 0.8 and later. Why you would assume I would either not know about this, or choose to lie about it, is beyond me - given I have far more familiarity with the code than you do, having worked with it on a daily basis for over a year, it might be worth giving me the benefit of the doubt, and assuming that I do actually know what I am talking about...

As previously stated, we are currently investigating the best long-term path for future development, because we have already established to our satisfaction that the existing optimisations cannot be applied to 0.8 without significant effort. Attempts by you to demonstrate otherwise are not helpful, and further "issues" of this nature will be closed with no further comment.