Proszę, nie używajcie systemu kontroli wersji #Mercurial.
Często mówi się, że Mercurial musi być dobry, bo używają go wielkie korporacje. To super… dla nich. W praktyce oznacza to, że rozwój Mercuriala skupia się na potrzebach tych korporacji, a jeżeli trafisz na problem, który ich nie dotyczy, to lepiej umieć przygotować łatkę.
Nie zapominajmy, że Mercurial bardzo długo nie wspierał Pythona 3. Pierwsze wydanie z wsparciem dla tej wersji wyszło dwa miesiące przed końcem życia Pythona 2.
Choć autorzy może nie mieli szczególnie entuzjastycznego podejścia do Pythona 3, to już mają je do przepisywania wszystkiego w Ruście. Żeby było śmieszne, Mercurial z rozszerzeniami w Ruście nie działa na Pythonie 3.12. Zdaje się, że autorzy postanowili użyć jakiegoś wynalazkowego interfejsu Python/Rust zamiast "standardowego" PyO3.
Nie będę nawet wchodził w temat problemów z wydajnością na platformach innych niż najpopularniejsze, błędów, których poprawienie zajęło wieczność (wciąż pamiętam, ile ten szajs potrafił się wieszać), i ogólny problem bycia dziwacznym, mylącym wynalazkiem dla każdej osoby, która używała Gita (czyli praktycznie rzecz biorąc, każdej osoby, która w tych czasach wysyłała łatki dla projektów wolnego oprogramowania).
🧵 …although I tend to favour OpenBSD and Linux for personal reasons, I find this decision OK. Certain open source projects lack clear, reasoned positions and decisions.
»NetBSD’s New Policy – No Place for AI-Created Code:
NetBSD bans AI-generated code to preserve clear copyright and meet licensing goals.«
Technicznie rzecz biorąc, sporą część pracy związaniem z portowaniem paczek #Gentoo do Pythona 3.13 można zautomatyzować. W gruncie rzeczy, mamy już większość potrzebnych elementów — narzędzia, by znaleźć potencjalne paczki, zaktualizować PYTHON_COMPAT, uruchomić testy. Dlaczego więc robię to na wpół ręcznie?
Po pierwsze, daje mi to okazję, by zajrzeć w ebuildy. Mogę poszukać starych problemów, poprawić kod, czasem odkryć paczki, które powinniśmy byli usunąć dawno temu. Po drugie, patrząc na logi czasem mogę zauważyć, że testy gdzieś nie działają poprawnie (a w szczególności przypadek, że paczka nie zwraca błędu, kiedy testy nie przechodzą).
No i koniec końców, daje mi jakieś poczucie wartości, kiedy przez tę przeklętą gorączkę nie mogę się na niczym skupić.
@mgorny Wut. Ależ to jest dziwne, ich repo z testami brzmi jakby twierdziło że to ze względu na to że nie wiedzą skąd się ich dane do testów oryginalnie wzięły (chyba?) i to wygląda jakby chcieli w ten sposób obejść ich licencjonowanie? Bardzo konfundujące. :blobfoxconfused:
@timorl, owszem, dziwne. Ja to czytam tak, że oryginalnie odziedziczyli te zaszyfrowane testy, a teraz starają się zrobić nowe, publiczne, ale też mają wątpliwą licencję.
Soo… say I have a couple ebuilds that are probably not great quality (approximately first ones I wrote), but work. How should I go about making these useful for other people? Perhaps even including them in the main gentoo repo? This is mostly about Request Tracker, which already is in the repo, albeit in an old version (and with a wrong makefile patch), plus some of it’s dependencies (some of which I updated, some that never were in the main repo).
The primary purpose of GURU is to maintain packages not present in the Gentoo repository. Forking (overriding) actively maintained Gentoo packages into GURU is prohibited. If the package is moved to Gentoo, it should be removed from GURU.
And www-apps/rt is already in the main gentoo repo, so I’m not allowed to put that there. :blobfoxcry2:
#Gentoo question; what is the best way to share a small improvement on an ebuild in the Guru repo? Asking to become a contributor sounds like overkill, with getting PGP working and all.
Would it be best to just create my own repo and add it to the list so it can be discovered?
(The improvement is making iio-sensor-proxy work on openRC by implementing a fix I found on the forums. Not that impressive, though now my Chromebook runs perfectly :))
If you liked similar software such as Calise and Redshift, and you are looking for an actively maintained solution, setting up Clight may be a good weekend project :)
I'm going to host an online workshop for the Gentoo e.V. on 2024-06-15 about how to "Host Gentoo dependency tarballs as GitHub releases".
I'll show how to use GitHub for dependency tarballs as an external #Gentoo#contributor, such as a proxied maintainer, a GURU committer, or an overlay #maintainer.
I use this approach to package #opensource#Golang software, and it can be applied to other similar situations, or even automated through local scripts or GitHub Actions.
We're FINALLY doin it again. Livestreamin' that is.
Come join us and laugh at how badly the #Gentoo journey will go. And while we're waiting for compiles, we'll be on the other side of the spectrum with composables? immutables? image based? whaaaa?