@yerinalexey nice, and I like sentence "Proprietary software should not exist" you are right. Also I learned something new, it is #Sourcehut, that people in there collaborate actually with emails. I don't have experience with coding nor Srht so this is valuable to me. Thanks.

sourcehut.org

@yerinalexey from Drew DeVault's linked article: "GitHub is a proprietary, commercial service, and their ultimate goal is to turn a profit."

Something to keep in mind for those "standardize on GitHub" loonies.

@yerinalexey what about suckless approach? No git, but they publish diff patches. suckless.org

@s Do they not have a git repository? What do you mean?

@yerinalexey Take for example their terminal emulator ST st.suckless.org/

You just download a .tar.gz from their website and if you want to customize your terminal you have to download and apply diff patches yourself st.suckless.org/patches/

@s That approach is kind of dumb. I would much rather use compiler options. So, if you don't need scrollback, you can use `make SCROLLBACK=no` instead of forcing everyone to deal with incompatible patches and other problems like that.

And also, they have a git repo: git.suckless.org/st

@yerinalexey suckless is about making your own thing rather than creating a bloated software with a million lines of code. Based on what you said you love Gentoo with all the compiler options. Also, that is a default git server, not Github. Github has become a centralized platform and ytdl got owned because of that. There is nothing bad in using git itself, don't you think so? It's platform agnostic after all.

@yerinalexey Checking if a feature or a combination of features (lord have mercy) is enabled, and controlling the program flow based on that, opens many backdoors for bugs. The idea behind suckless is good IMO, since it keeps the code simple and lean. If you want a feature that might introduce bugs, you are free to add it yourself. The thing that bothers me about them though, is that they take this philosophy to the point where the code is unreadable.

@gerazo Ezzel most konkrétan nem értek egyet. Nem tudom, kinek mennyire jó kliensei és addonjai vannak az e-mailes kontribúcióhoz, de a "én 10 patchet beküldök míg te 1 PR-t" szerintem túlzás. A patched tartalmát ígyis-úgyis megőriznéd valahol, nem csak a gépeden. Az emailből elveszik, a gépedről elveszik, egy mentés nem mentés. Tehát ígyis-úgyis lenne egy repód, nevezzük forknak vagy bárminek. Innentől kezdve megformázni az emailt és beküldeni pontosan ugyanannyi, mint megnyomni 1 gombot.

@gerazo Ráadásul, én hülyét kapnék attól, ha plaintext mailekben jövő random patcheket kéne, adott esetben zéró parent infókkal, mergelgetnem ide-oda. Meg attól is, ha ezek a dolgok e-mailben közlekednének. Elveszik, zajos, ráadásul pl. a céges e-mail rendszer még szét is cseszi a leveleinket, ha bármilyen 3rd-party link (pl. reviews.llvm.org...) szerepel benne, de ez az Ericsson faszsága nyilván.

@gerazo Nekem valahogy jól esik az, hogy a diff highlightolva van és színes, hogy látszik hozzá a beszélgetés (pl. hogyan vezényelsz le egy e-mailhez csatolt patch fájlon soronkénti/hunkonkénti részre érvényes diszkussziót?! Olyat, ami valamennyire "threading" kompatibilis *is*...)

Az, hogy az egy konkrét provider gáz, azzal egyetértek. De ahogy az e-mail comms elveszik azok számára akik később jönnek a projektbe, ugyanúgy elveszik az MR kommentjei is, ha ugrik a repó, vagy a providere.

@gerazo Az más kérdés, ha már reviews.llvm.org, hogy a Phab mondjuk kiküldi a mailhez levlistára, és lehetővé teszi, hogy patch fájlt tölts le. De egy ekkora projektnél egyszerűen esélytelen, hogy rajta legyél a levlistán. Olyan méretű zaj érkezik, hogy nagyon hamar a "skip inbox and move to Trash" lenne a levlistára alkalmazott szabály... akkor meg minek?

@gerazo Elhiszem, hogy ha valaki self-hosztolja az emailjét, ha egy gépe van, amin van a saját mail domain szerója, stb. stb., akkor úgy pimpeli ki, ahogy akarja, de történetesen én el nem tudom képzelni, hogy bármi értelmeset tudnék kezdeni akár a Protonmail, akár az Office 365 levelezésembe érkező patch fájlokkal...

@szalayricha Természetesen ez elég radikális írás és én sem értek vele egyet. De azért sok igazság is van benne. Elképzelhető lenne egy elosztottabb model, aminél a fogadó is jobban tehermentesítve van. Nincs nagyon kihasználva a git elosztottsága.

@gerazo Ez tény. Főleg, hogy GitHub-on minden fork igazából egy közös repó és csak be vannak huzalozva a refspecek... Ahogy azt a #youtube-dl fiaskó meg is mutatta amikor a DMCA repóba betolták a projekt történetét. 🤣

Sign in to participate in the conversation
Mastodon

This is a brand new server run by the main developers of the project as a spin-off of mastodon.social 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!