PFS-utils на github

[neobht]

Печально, если не сможете на github держать всегда актуальную версию.
Сочувствую Zay в попытке держать там актуальную версию, когда остальным три команды в консоле запомнить тяжело.

Я бы даже предложил Zay вообще не переносить последние сторонние наработки туда. Пусть будет много разных версий, а еще лучше чтобы они были несовместимыми. Выкладывать на github только свои наработки, как руководителя этого направления и те, которые посчитаются правильными.

Какая-то свалка из года в год.

[sfs]

Печально, если не сможете на github держать всегда актуальную версию.

Для кого ее там держать? Она там уже не 1 год валяется. Никому не нужна. Какое-то движение только здесь. Zay давно и похоже навсегда  отошел от темы - о каком руководстве речь?

[neobht]

Держать для тех, кто вносит правки.
Иногда полезно думать не только о себе.

[sfs]

Правки вносит только Zay. Берет из этой темы. Т.е. сам для себя? А смысл?
Я тестирую и вношу в дистр, имеющий хоть и небольшое, но сообщество. В итоге эта тема жива. Кто думает "только о себе"?
Тему с гитхабом замутили Вы 2 года назад. Что сделано за эти годы? Смысл поддерживать мертворожденное?

[neobht]

Мертворожденым его делает нежелание работать по нормальному совместно.
Хорошо, что Zay все же переносит правки.

Но это ужас вся эта канитель по просмотру вложений. Работайте нормально. Все только выиграют.

[sfs]

ander всего месяц, как появился на форуме , а уже сделал больше чем остальные за 2 года. Причем без нытья про то что "плохому танцору и" отсутствие гитхаба "мешает" 
Кто хочет, тот ищет возможности, кто не хочет — ищет причины

[neobht]

Два года все уверяли, что ошибок существенных нет.
Ander внес скорее более универсальный код, менее прибитый гвоздями.
А если бы это делалось нормально через git, то эффективность была бы еще выше. Не приходилось бы дополнительно выполнять diff чтобы посмотреть на изменения.

Не понимаю, зачем пытаться доказать правильным неправильный подход. В каше выложенных версий в этой теме может разобраться только разработчик и то если в основу возьмет последний вариант. Поэтому еще надо смотреть в какую версию внесены новые правки.

[Zay]

Насколько мне известно, в PR никто не обновляет pfs-utils
Соответственно github версия нигде не используется и не тестируется. Разработки на github у нас не прижились. Может это и плохо , но факт

Это плохо. Но поскольку минимальное тестирование я проводил, и ничего принципиального в коде не менял, то вероятность наличия ошибок не велика.
В случае, если ошибки всё же будут найдены, в простом линейном (без функций) коде их вполне возможно найти и исправить (как ander с fileinpack).

ИМХО, в таких скриптах лучше вообще не использовать функции.

Почему?

Потому что существенно затрудняет читаемость и понятность кода.
Если нужно вынести какой-то функционал - то в отдельный скрипт.

Монтирование через loop - сделано для Puppy-подобных систем

Хорошо бы оставить совместимость, но неизвестно, юзает ли кто pfs-utils в пупи...

Никаких причин ломать совместимость нет. И кроме Puppy(Rus) есть другие дистрибутивы с AUFS.
"Официальный" PFS-utils претендует на максимальную универсальность и дистро-независимосить.

Два года все уверяли, что ошибок существенных нет.

А их и нет, насколько я знаю. Ошибки, описанные в этой теме, я постарался устранить.

Ander внес скорее более универсальный код, менее прибитый гвоздями.

Подход ander, по моему мнению, верный!
Но он взял за основу уже "прибитый гвоздями" вариант кода из PRA, а не GitHub'овский.
Поэтому суть его предложений, в данном случае для меня, пока что, не очень понятна.

Я бы даже предложил Zay вообще не переносить последние сторонние наработки туда. Пусть будет много разных версий, а еще лучше чтобы они были несовместимыми. Выкладывать на github только свои наработки, как руководителя этого направления и те, которые посчитаются правильными.

По факту так и происходит. На GitHub выкладываются практически только багфиксы.
Исключение - отказ от привязки к busybox и создание прослойки для универсальности.
Но - (см. ниже):

Zay давно и похоже навсегда  отошел от темы - о каком руководстве речь?

В некоторой степени - да, это так. Свободного времени у меня теперь не столько, как два года назад.
Но причина ещё и в том, что когда Pro перестал развивать PuppyRus, обратная связь по сути пропала.

[sfs]

Я не против гитхаба в принципе. Но в данном случае это пустая трата времени Zay. Нет у нас разрабов уровня гитхаба. Доработок мало

Доработал fixmenus и сопутствующее

[neobht]

Я не против гитхаба в принципе. Но в данном случае это пустая трата времени Zay. Нет у нас разрабов уровня гитхаба. Доработок мало

Ну чепуха же!!!
3 строчки последовательно выполнить - менее 1 минуты.

Причины надуманы.

Вот Ddshurick в свое время выложил Richy и я почти сразу внес более читаемое форматирование кода. Вроде бы мелочь, но читать мне самому стало гораздо проще, потому и доку на три параметра не прошу. Конечно, если не открывать код, то просить доку можно очень долго. А писать доку на init такого уровня - это писать в два, три раза больше текста, чем сам код - это неразумно.  Сам код и должен быть докой для разработчиков. А пользователям дока не нужна, потому что их нет, потому что скрипты не используются.

[Zay]

Нет у нас разрабов уровня гитхаба. Доработок мало

neobht уже столько раз пытался донести мысль, ну и я попробую:

Не надо никакого "уровня" для работы с GitHub!
Проект PFS-utils уже не требует значительных модификаций (максимум багфикс) - тем более рационально использовать GitHub.
Пример: тот же багфикс от ander потребовал одного простого коммита! Такие коммиты можно и в браузере делать (я делаю).
А "по старинке" вместо этого одного коммита родилась бы очередная "полу-совместимая" с оригиналом модификация.

Но проблема, похоже, не в этом, а в том что по факту в PRA скрипты PFS уже не оригинальные, а со своими "наворотами".

[sfs]

Проект PFS-utils уже не требует значительных модификаций

Если не юзать - то да 
Чем тогда мы в этой теме занимаемся?
Кроме того на гитхабе не было и нет менеджера модулей и зависимостей.
Поскольку Zay на форуме редкий гость - не вижу смысла в дополнительных бюрократических процедурах по добавлению коммитов
Надо ориентироваться на действующих разрабов. Если ander удобнее с гитхаб - мне без разницы. Других заинтересованных в доработке не вижу. Ориентироваться на неразрабов не готов.
Гитхаб - для разработки. А не разработка для гитхаба

[Zay]

Чем тогда мы в этой теме занимаемся?

По сути - очисткой скриптов от того лишнего, что было внесено туда в PRA.

Кроме того на гитхабе не было и нет менеджера модулей и зависимостей.

Зависимости есть, только их никто не использует.
А менеджер модулей - опять же спец. функционал PRA, к тому же реализованный с другим подходом.

Поскольку Zay на форуме редкий гость - не вижу смысла в дополнительных бюрократических процедурах по добавлению коммитов

Изначально сложности были не от бюрократии, а от того что никто не захотел разобраться с Git'ом.


Подведём итоги:

PFS-utils на GitHub - это уже готовый инструмент.
Принципы, заложенные в основу его разработки:

   Максимальная универсальность.
   Простой, краткий, легко читаемый код.
   Всё это - не в ущерб быстродействию.


Все обнаруженные баги я постарался исправить (во многом - с помощью других разработчиков, к каждому коммиту есть комментарий, с указанием авторства идеи или кода для исправления).

ИМХО - добавлять новый функционал непосредственно в скрипты PFS-utils не нужно! Функции, которые нужны в конкретном дистрибутиве - можно добавлять как отдельные скрипты, вызываемые из скриптов PFS (как fixmenus).

Опять же ИМХО, но я, как и раньше, против превращения скриптов PFS-utils в помойку, куда запихивают код на уровне качества "работает - и ладно", плохо читаемый, с кучей функций и прибитый гвоздями к конкретному дистрибутиву. Такой код ни одна другая команда не возьмёт в свой дистрибутив, и даже не будет его изучать. И тогда на PFS-utils как универсальном инструменте будет поставлен крест.

[sfs]

я, как и раньше, против превращения скриптов PFS-utils в помойку, куда запихивают код на уровне качества "работает - и ладно",

Да. такая проблема есть. Мало разрабов. Мне не разорваться

В чем специальность Менеджера модулей для ПРА?
Инструмент загрузки пакетов не нужен как универсальный?

[ander]

Ну застыдили, застыдили.
Ну выучил я несколько команд git, сделал commit в своем локальном репозитории, внеся те же исправления в pfsload/unload.
Взятые с github pfsload/pfsunload, кстати, не так уж и отличались от тех, что были в PRA.
На github зарегистрировался как andreyrogojin.
А дальше что?  push  я все равно сделать не смогу, надо ж как-то меня туда добавить.
А потом пусть neobt попробует на diff посмотреть и скажет, сильно ли git ему это облегчил.
Если строчку-другую исправлять, то понятно, diff поможет, а вот если условия другим концом поразворачивать, то кажется, что почти все изменилось, хотя по сути изменений и немного.