weekly update

_posts/mini_posts/2024-04-09-opensource-responsibility.md

@@ -0,0 +1,12 @@
+---
+layout: post
+title: Ответственность разработчиков за бесплатный код
+tags: [softskills, мысли]
+---
+В недавней истории с `xz` примечательны не только технические детали, но и [социальный аспект](https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/). Вкратце, от основного мейнтейнера довольно токсично требовали улучшений и ответственности перед сообществом. Такая история не очень нова: например, несколько лет назад создатель actix, одного из самых быстрых тогда веб-серверов на Rust, был на грани [удаления репозитория](https://github.com/fafhrd91/actix-web-postmortem), но в итоге все закончилось нормально (хотя там и к самому разработчику [были вопросы](https://deavid.wordpress.com/2020/01/18/actix-web-is-dead-about-unsafe-rust/)).
+
+"Знаете, я и сам своего рода opensource-разработчик". Одна из зон моей ответственности — первичная фильтрация поступающих запросов от пользователей (за год с небольшим [прокомментировал](https://github.com/gradle/gradle/issues?q=commenter%3Aov7a) больше чем на 1000 тикетов 🤯). И сначала я довольно дотошно отстаивал позицию "пользователь всегда прав, если он не даун", да и тяжело было с некоторыми не соглашаться, когда они критиковали продукт. Но через год мое отношение к пользователям немного сместилось. 
+
+Увы, есть люди, отношение которых напоминает поведение стереотипных теток с барахолок, которые будут требовать от тебя доставку на дом вещи, которую отдаешь бесплатно, а потом еще навалят говна, что она неидеального качества. У нас есть "любимчики", которые могут вылить поток сознания перемешанный с несвязной критикой продукта или добавить в заголовок текст ошибки и приложить проект на 10 000 строк, на котором она воспроизводится. До [ядерных угроз](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644#c4) пока не дошло, но некоторые ходят прям по грани Code Of Conduct. Разумеется, это не означает, что все такие, нормальных и адекватных — большинство. Но хорошо оформлять тикеты, заботясь о продукте, сообществе и разрабах, а не только своей проблеме, мало кто умеет.
+
+До меня наконец дошло просветление, что в данном случае с большой силой не приходит "большая ответственность". Продукт с открытым исходным кодом, в лицензии четко написано, что [гарантий никаких не даем](https://felixge.de/2013/03/07/open-source-and-responsibility/), предоставляется бесплатно. Если что-то не нравится — либо помоги (хорошим тикетом или PR), либо форкни, либо найди что-то другое. Говорить "нет" и закрывать мусорные тикеты — это [нормально](https://opensource.guide/best-practices/). Мысли вроде очевидные, но за год мне стала гораздо ближе и понятнее позиция "старожилов", которым проще закрыть мутный тикет и подождать нормальный, если проблема действительно существует, чем пытаться найти в нем что-то полезное.

_posts/mini_posts/2024-04-11-git-garbage-collection.md

@@ -0,0 +1,10 @@
+---
+layout: post
+title: Сборка мусора в git, GitHub и GitLab
+tags: [git, github, gitlab]
+---
+Как удалить коммит, который не принадлежит ни одной ветке, из git? Выполнить _на сервере_ `git gc`.
+
+Как удалить такой же коммит с GitHub? Похоже, что никак [[1](https://stackoverflow.com/questions/9135095/git-gc-aggressive-push-to-server), [2](https://stackoverflow.com/questions/4367977/how-to-remove-a-dangling-commit-from-github/4368673)], ну или [через поддержку](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository#fully-removing-the-data-from-github) или удаление всего репозитория. В [GitLab](https://docs.gitlab.com/ee/administration/housekeeping.html) такая функция есть.
+
+Разумеется, сборка мусора — [очень непростая задача](https://github.blog/2022-09-13-scaling-gits-garbage-collection/).