Пулреквесты и иже с ними

[DJ VK]

В качествен эпиграфа грустный анекдот на тему:
Пользователь-чайник: Вышла новая версия компонентов для "Планеты"
IT-специалист (супер-пупер программист): Ждем от Вас пулреквестов

В эту тему давайте высказываться по двум вопросам:
1) как делать пулреквесты. Я их давно не делал и забыл совсем как их делать. Давайте сделаем инструкцию.
2) насколько фраза "ждем пулреквестов" в реальности тормозит развитие программы...

Касательно второго вопроса - мы не станем обсуждать хотелки с одной кнопкой "сделать круче!!!" Рассмотрим ситуацию когда есть конкретный код (алгоритмы, библиотеки итд...). Но встречаются такие люди, как Вася Пупкин - крутой дизайнер, способный одними линиями нарисовать на api азимутальное кольцо с компасом красоты неописуемой. Или математик Коля Сидоров, который знает как рассчитать на паскале, используя, скажем параллельные вычисления, километровую радиальную сетку.... Что они услышат? Ждем пулреквестов.
У меня напрашивается вывод, что в развитии программы больше всего заинтересованы пользователи. Это могло бы быть смешно если бы не так грустно...
Я способен написать алгоритм "волшебной палочки", которая создает выделение по карте заполнения. Но это просто итератор, который при включенной карте заполнения создает полигональное выделение по ее периметру или по ее отсутствию (например в пределах экрана). Но это алгоритм - простая функция, которая никуда не подключена. Более того она потребует еще одной функции которая говорит есть ли карта заполнения в данной точке, которую я могу тупо не удостоить своим вниманием. К чему приведет позиция "ждем пулреквестов"? К точу что эта фича скорее всего не появится никогда.
Аналогично выделение "лассо" - тут даже алгоритм не нужен (точнее нужен один - чтобы делать аппроксимацию линиями). Просто за мышкой генерим точки полигона часто-часто. Но Я не факт что стану ломать голову где взять алгоритм построения полигона и переделать его. Есть лишь идея... А Икеи не будет...
Все-таки нормальная ситуация, когда видно, что разработчики - самые заинтересованные в развитии программы лица. Несколько лет назад именно ночнушки и были полигоном для всевозможных экспериментов, а сейчас там платные хотелки появляются...

p/s/ уже давно пора перевести все дочерние формы на fmx (если это возможно одновременно с vcl) пожертвовать перетаскиванием тулбаров и избавиться от динозавра toolbar2000, и так далее... Но это процесс не на один месяц, никакими пулреквестами он не покроется, здесь только воля и целеустремление основных разработчиков все решает...

[vdemidov]

Мне интересно кому адресован этот пост. Называйте уже по именам
А еще чего вы хотели добиться написав его?

Все-таки нормальная ситуация, когда видно, что разработчики - самые заинтересованные в развитии программы лица.

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

У меня напрашивается вывод, что в развитии программы больше всего заинтересованы пользователи.

Бинго.

[DJ VK]

По второму вопросу чисто философский интерес. Если есть код и появится в каком нибудь Sas4OS/2 какой нибудь супер-пупер инструмент, то не автор кода же виноват в том что в обычной sas планете нет такого инструмента. Но видеть, что его там нет немножечко больно. Хоть и не свое детище, но почти родной проект, переживаем-с....

Где взять разработчиков? Я На роль разработчиков не гожусь. Я по складу ума генератор идей. Разработать и воплотить на коленке с нуля - это да. А "встроить" хрен знает во что - это не мое. Неужели это противоречие (хочется развития программы, но нет возможности заниматься чисто техническими деталями) не разрешимо?
Я работаю в коллективе и там где не понятно пинаю коллег до посинения пока они не разжуют все так, чтоб стало понятно. Иногда даже кто-то что-то кодит для меня))). Здесь чувствуешь себя почти один на один с огромным кодом...

Если мой проект стал сложный я просто разбираю его на кусочки и собираю снова, но стараясь сделать его в 10 раз прозрачнее. Если бы мне у себя попался код из двух юнитов (юнит и интерфейс) - второй бы в ту же секунду прекратил свое существование. Неоптимально. Непонятно. Значит в топку. Планета с сотнями интерфейсов больше походит на Microsoft SDk, DDK, DirectX SKD, или исходники RAD STUDIO. Эдакий недоступный для удержания целиком(!) в голове - а значит недоступный для понимания. Я не обсуждаю удобство использования. Я про удобство восприятия кода.

Сотни интерфейсов. Тысячи наследников гибридов группового спаривания абстрактных классов с множественными интерфейсами во всевозможных позах комбинациях. Зачем? А чтоб враг не догадался (а "Вассерман" с горя подсел на порошок) каждая сущность (проекция, инструмент, тайл, карта) равномерно размазана по десяткам юнитов. Каждый метод казалось бы класса (отрисовать, загрузить, прочитать настройки) превращен в наследника от абстрактного класса но со своим буквально уникальным параметрами. Мрак и Хаос.

Пример обратного:

Код: Выделить всё

Sas.Next: Картографический движок. Несколько родительских слоев.
1)Слой для карт. на нем 4-5 дочерних слоев (каждый соотвествует одной из т.н. набора карт). Под каждую карту создается свой кэш загруженных тайлов и поток загрузчика из хранилища. Несколько колбэков замыкают связи между сущностями. Весь родительский слой двигается, крутится и масштабируется целиком. Вся модификация карты (прием загруженных тайлов, отображение, составление  нового списка тайлов, и его запрос) - одна процедура procMap вызываемая из главного таймера программы. и то уже не нужно, ибо достаточно Synchronize сделать
2й слой - объекты на карте. очень легко добавить еще два-три. Для полигонов, для сеток (причем можно tcollection сделать. Сколько надо градусных сеток столько и воткнем одновременно парой сотен строк кода.
Весь движок - 6 файлов. (сотни в 3 килобайт) Из них за слои карт отвечает 4. Абстрактных классов - 1шт. Под разные типы хранилищ :D

не спорю, FMX предполагает полное отсутствие отрисовки. никаких GR32, OnDraw, OnPaint. Вообще. Но не это главный враг sas.планеты. Нужна масштабная реорганизация кода. Прозрачность. Строгая четко просматриваемая иерархия классов.
*Вот менеджер закачек. Сам по себе. Внутри список задач, в каждой крутится поток. И список интернет подключений (поддержка списка прокси). Колбэки на отрисовку формы менеджера закачек, листбокс или таблица с некоторым кол-вом прогрессбаров.
*Вот картографический движок. Внутри Список активных слоев карт. Список сеток, список накладываемых на карту инструментов.
*Вот модуль навигации. Сам по себе.
Каждая сущность должна жить в пределах своего класса и ничего не наследовать без надобности. Абстрактных классов - по пальцем сосчитать. Там, где разные от слова совсем-совсем. Тайлохранилища. Плагины. Инструменты. и виртуальными в них только уникальный набор данных и своя отрисовка. Последовательность выполнения всех операций - строго в абстрактном классе.
такая вот полная переструктуризация и откусывание лишнего. группирование кода где возможно в один. ну например каждый экспорт кэша имеет внутри свой поток. Зачем? именно для такого абстрактные классы и придуманы. Три виртуальных метода - начало экспорта, добавление тайла и завершение. Есть поговорка - если один и тот же кусок кода вызывается более 2х раз надо вынести его в функцию. А теперь считаем

Код: Выделить всё

u_ThreadExportToArchive.pas
u_ThreadExportToAUX.pas
u_ThreadExportToIMG.pas
u_ThreadExportIPhone.pas
u_ThreadExportToJNX.pas
u_ThreadExportKML.pas
u_ThreadExportToMBTiles.pas
u_ThreadExportToOgf2.pas
u_ThreadExportToOruxMapsSQLite.pas
u_ThreadExportToRMapsSQLite.pas
u_ThreadExportToRMP.pas
u_ThreadExportToCE.pas
u_ThreadExportAbstract.pas
u_ThreadExportYaMobileV3.pas
u_ThreadExportYaMobileV4.pas

14 одинаковых классов !!!!

Информация о тайле. Тайлы самые обычные. Казалось бы и класс для хранения информации о тайле должен быть один (ну или два если векторные тайлы шибко отличаются). Считаем

Код: Выделить всё

ITileInfoBasicMemCache
ITileInfoBasic
ITileInfoWithData
IPredicateByTileInfo
TTileInfoBasicBase
TTileInfoBasicNotExists
TTileInfoBasicTNE
TTileInfoBasicExists
TTileInfoBasicExistsWithTile
TTileInfoBasicMemCache

минимум 10 классов для одной сущности

Да проект проекту рознь. Но Для чего я трачу кучу времени на переписывание своих проектов почти заново - Чтобы заказчики меня не проклинали а памятник хотели поставить... Вдохнуть в него новую жизнь, сделать его лучше, понятнее. Чтобы через 5 лет найти то или иное место в коде с бодуна не составило труда... И с таким подходом к жизни (пусть всем будет удобнее) ковыряние в этой планете вызывает тоску смертную... Труп реанимируем.
Отсюда пожелание. Разработчики, если будет времени немного, продумывайте по чуть-чуть те или иные места программы - а как бы я сделал если писал эту штутку заново. Готов помочь идеями и начирикать визуалку если где надо...

[vdemidov]

Я еще раз повторю вопрос: "Кому адресован весь этот плач Ярославны?"
Попытаюсь чуть упростить ответ на него. Возьмем статистику коммитов за последние 5 лет:
Viktor Demidov - 1,100 commits (Надо же, какое круглое число ненароком вышло, я не специально)
zed - 727 commits
Sergey Gаvrilеnkо - 106 commits
Aleksandr Alekseev - 16 commits
Alex Whiter - 8 commits
Alexandr Dolgov - 3 commits
Pavel Gordeyko - 1 commit

К кому из этого списка претензии и на каком основании?

По второму вопросу чисто философский интерес. Если есть код и появится в каком нибудь Sas4OS/2 какой нибудь супер-пупер инструмент, то не автор кода же виноват в том что в обычной sas планете нет такого инструмента.

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

Где взять разработчиков? Я На роль разработчиков не гожусь. Я по складу ума генератор идей. Разработать и воплотить на коленке с нуля - это да. А "встроить" хрен знает во что - это не мое. Неужели это противоречие (хочется развития программы, но нет возможности заниматься чисто техническими деталями) не разрешимо?

Я сейчас неприятную вещь скажу, вы не обижайтесь, но обычно такие генераторы идей просто не понимают реальную разницу между "на коленке с нуля" и стабильным поддерживаемым кодом в плане трудоемкости.

Здесь чувствуешь себя почти один на один с огромным кодом...

Я хоть раз отказался отвечать на содержательный вопрос по коду? Покажите пример - я постараюсь исправиться.

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

Временами да, неоптимально, но увы в старых Делфи не завезли умных указателей с подсчетом ссылок в обычные классы, только в интерфейсные. А это означает что приходится в любом случае городить огород.
Но так далеко не всегда. Бывает, что интерфейс нужен именно для отделения интерфейса класса (извините за тавтологию) от его реализации и зависимостей этой реализации. Ну и случаев, когда реализаций много, также полно.

Планета с сотнями интерфейсов больше походит на Microsoft SDk, DDK, DirectX SKD, или исходники RAD STUDIO.

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

скрытый текст: показать

В качестве примера: добавляем поддержку во встроенном браузере специальных ссылок на картинки в папке MediaData, что бы можно было не писать абсолютные пути, казалось бы при чем тут импорт меток, тут задача только для браузера? А вот если импортируем jpg с геотегами, то в описание метки автоматом вставляется ссылка на картинку и нужно проверять не лежит ли картинка уже в MediaData и заменять абсолютный путь на специальную ссылку. Все теперь экспорты должны знать о этом специальном формате ссылок и иметь ссылку на текущий конфиг, в котором задан путь к актуальной папке MediaData. И вот таких неочевидных связей в процессе разработки реального удобного в использовании инструмента, а не сделанного на коленке костыля - возникает огромная куча в самых неожиданных местах.

ну например каждый экспорт кэша имеет внутри свой поток. Зачем? именно для такого абстрактные классы и придуманы. Три виртуальных метода - начало экспорта, добавление тайла и завершение. Есть поговорка - если один и тот же кусок кода вызывается более 2х раз надо вынести его в функцию. А теперь считаем 14 одинаковых классов !!!!

Отличный пример. Вы реально заглядывали в эти файлы? Вот чисто ради интереса хоть один открывали? Покажите мне хоть в одном из свой поток, кроме как в названии?

скрытый текст: показать

Да, нужно переименовать. Если есть время и желание помочь в развитии проекта, то можете заняться

Информация о тайле. Тайлы самые обычные. Казалось бы и класс для хранения информации о тайле должен быть один (ну или два если векторные тайлы шибко отличаются). Считаем

Ну, во-первых, смешались в кучу кони и люди, классы и интерфейсы, также те кто их используют .
Интерфейсов всего два ITileInfoBasic - базовая информация о тайле, ITileInfoWithData - то же что в первом, но еще есть само содержание тайла, если он существует.
А вот это уже реализации.
TTileInfoBasicBase - базовый класс
TTileInfoBasicNotExists - если тайла нет, то просто заглушка. возможно стоило обойтись просто nil
TTileInfoBasicTNE - присутствует tne и соответственно хранится дата его создания
TTileInfoBasicExists - тайл присутствует, вся информация о файле, но самих данных нет
TTileInfoBasicExistsWithTile - то же что в прошлом, но уже есть данные
Да, возможно стоило ограничится одним интерфейсом с признаком наличия данных и одной универсальной реализацией. Возможно. В свое время мне показалось, что так лучше. Возможно я был не прав, но, в любом случае, то что было до появления этих интерфейсов было еще более запутано.
Все остальные пункты, приведенные вами, это то что использует ITileInfoBasic для своей работы.

Но Для чего я трачу кучу времени на переписывание своих проектов почти заново

Это говорит не в вашу пользу.

Вдохнуть в него новую жизнь, сделать его лучше, понятнее. Чтобы через 5 лет найти то или иное место в коде с бодуна не составило труда... И с таким подходом к жизни (пусть всем будет удобнее) ковыряние в этой планете вызывает тоску смертную... Труп реанимируем.

Печально видеть такую оценку 10 лет свой работы, но видимо вы правы. Е-сь с этим кодом сами. В дальнейшем любые хотелки и идеи только за деньги. Вы своего добились. Труп - так труп.

[DJ VK]

Но Для чего я трачу кучу времени на переписывание своих проектов почти заново

Это говорит не в вашу пользу.

Не согласен. От слова абсолютно. Каждая новая версия программы намного удобнее, понятнее и лучше воспринимается заказчиком и другими программистами. Надо понимать, что мы в отделе НИОКР, работаем с реальным железом, приборами, и никто ничего не знает что в конце получится. Даже заказчик, написавший ТЗ толком ничего не может сказать. Лишь полностью насладившись работой с готовой программой можно понять что в ней хорошо а что плохо. Начинаешь переделывать - код растаскивается и раскладывается по полочкам. Оно само так получается. Просто и удобно. Даже дивиться начинаешь насколько лучше стало. Просто старая и новая программа - это две разные программы. И предполагающие разный подход к узлам, данным и особенно к их осмыслению.

Печально видеть такую оценку 10 лет свой работы, но видимо вы правы. Е-сь с этим кодом сами. В дальнейшем любые хотелки и идеи только за деньги. Вы своего добились. Труп - так труп.

скрытый текст: показать

Воистину, в России по морде первыми получают те, кто хотел как лучше...

Я не это хотел сказать. Искренне прошу извинений, что обидел Вашу работу. Я правда не хотел никого обидеть. Не труп, а просто философски черезчур громоздкая и неудобная. Простите уж, господа разработчики.
Я же про принцип Оккама: "Не следует привлекать новые сущности без крайней на то необходимости". Он ведь не программистский, а философский. Чтобы упростить восприятие людьми кода количество сущностей (классов) стоит строго ограничить.... А нынешний код даже и близко не похож на учебник для студентов по Делфи: Массивы-Листы-Записи итд... Откуда же они тогда набегут и прикрутят новые функции?? Студенты и только студенты обладают огромными ресурсами времени и желания что-то делать с кодом. Если код для них понятен, естественно.
Я программист с большим стажем, но и для меня этот код с доступен для понимания местами и кусками. Я не обвиняю никого лично. Просто это не хорошо. Я рассказываю как у себя борюсь с сложностями в коде. Не для критики, а для того чтобы сказать, что совершенство возможно. Но это почти равносильно тому, чтобы написать программу заново... Отсюда и метафорическое сравнение старого кода с мертвыми...
Лично для себя ничего не просил и не собираюсь. Я в этом плане стараюсь для всех. Например сейчас я все еще предлагаю новый кэш, а не прошу для меня его написать. Да это моя программа, мой формат, но сам я могу лично для себя запаковать обычный тайловый кеш не внося изменений в планету. Исключительно для всеобщего удобства я трачу время на совмещение его с программой. И слышу - только за деньги. Тоже неприятно знаете ли...
Надеюсь НИЧЬИХ пулреквестов это не касается??
И напоследок я обращаюсь не столько к Демидову, сколько ко всем кто будет в будущем работать с программой. Если разложить код по полочкам станет намного удобнее. И программа переживет своих клонов и альтернативы... Уважаю планету и желаю ей только хорошего. Именно поэтому и переживаю, и пишу тут.

[vdemidov]

Простота не предшествует сложности, а вытекает из нее.
— Алан Джей Перлис

Простая и понятная архитектура - это результат большого количества вложенных усилий.

Отсюда и метафорическое сравнение старого кода с мертвыми...

Та нет. Просто Делфи уже давно труп. Я бы давно переделал все это добро на С++, но без какого-нибудь автоматического транслятора это просто не реально.

Надеюсь НИЧЬИХ пулреквестов это не касается??

Нет, но выводы я, в любом случае, сделал.

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

Вы этот формат делаете просто для себя или по работе?

Исключительно для всеобщего удобства я трачу время на совмещение его с программой.

Та ладно. Какое всеобщее удобство, если этот тип кэша еще нигде не используется и будет ли он нужен кому-то из пользователей САС совершенно не очевидно.

И напоследок я обращаюсь не столько к Демидову, сколько ко всем кто будет в будущем работать с программой.

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

[DJ VK]

Простота не предшествует сложности, а вытекает из нее.
— Алан Джей Перлис
Простая и понятная архитектура - это результат большого количества вложенных усилий.

Да. Говорят гениальное просто, но усилий требуется немало. Только методом проб и ошибок. Переписыванием кода.

Я сишник. И UI дизайнер. Обращайтесь, если что.

скрытый текст: показать

Собственно поэтому мне нравится как просто и иерархично устроены классы в VCL и FMX и сложно смотреть на конструкции для работы с базами данных.

Переводить на С++ смысла мало. Надо писать классы заново. но с учетом опыта эксплуатации. Если есть тайлы пустые, непустые, растровые и векторные, то и классы тайла надо писать общий класс, но учитывающий уже накопленную годами всю специфику.
Просто узел за узлом переводятся в новый проект.
Узел 1. Начать с менеджера карт. Сделать нормальное описание карты (1й класс), чтение и запись его из params.txt(вся работа с zmp в результате подключается к нему). Сделать менеджер карт (2й класс) с типизированным листом и методами добавления, удаления и сортировки. 3й класс - редактор описания карты. 2 формы - список и редактор. Архивация zmp сначала не обязятельна на первом этапе. ибо лечится распаковкой.

Узел 2. Графический движок. По мотивам sas.next. 1й класс - Движок отработка мыши, goto итд. Рассчитывает экранные координаты и передает слоям на обновление карт.
Далее только про карты. 2й класс - Список слоев. Несколько независимых слоев в которые можно назначать для просмотра по одной карте. 3й класс - слой карты. Имеет свой кэш(4й класс) и свой загрузчик (5й класс). кэш организован как список тайлов(6й класс). Тайл с описанием - 7й класс. Между кешем и загрузчиком воткнута очередь загруженных тайлов (8й класс). к загрузчику примыкают тайлохранилища. Задача на загрузку - список xyz - 9й класс, Собственно задача загрузки - запись XYZ - 10й класс.
Второй узел я сейчас реализую на с++. Единственное что у меня количество тайлохранилищ ограничено и не предусмотрен экспорт кэша...

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

Далее понемногу к ней пришивать:
Узел 2. Добавляем Слои для меток-полигонов, слои для Сеток и других инструментов.
Узел 3. Список меток, полигонов и путей. По аналогии со списком карт. Минимизируется кол-во классов, описание делается универсальное. Подбирается формат хранения. Если стандартные форматы планеты не подходят то в последующем делается импорт SML.
Узел 4. Процессор тайлов. экспорт, копирование. требуется обмозгование.
Узел 5. Процессор загрузки. Современный а-ля download manager с единой формой загрузок и множеством прогрессбаров.
Узел 6. Навигация.

В качестве графики я бы предпочел fmx. Кроссплатформенность, неплохая прозводительность. Да палеты компонентов у него небольшие. Но неведомое кол-во прозрачных слоев и поддержка визуальных стилей позволяют сделать почти все по новому и со вкусом.

Можно проще - можно. переводим основную форму Создаем c++ Builder проект. Добавляем в него pas файлы. И по одному от родительского к дочерним заменяем на cpp. При этом проект остается полностью живой имея внутри и cpp И pas

Примеры FMX:

[garl]

Ух и понаписали Вы тут

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

Выход:
или эти хотелки делает разработчик или эти хотелки делает сам пользователь (ждём пулл реквестов).
Есть "мэйн" разработчики и они принимают решение и несут ответственность за то какой будет программа и в какую сторону она будет развиваться.
И обиды на непринятие пул реквестов или нежелание делать ту или иную хотелку быть не может.

А нынешний код даже и близко не похож на учебник для студентов по Делфи: Массивы-Листы-Записи итд... Откуда же они тогда набегут и прикрутят новые функции?? Студенты и только студенты обладают огромными ресурсами времени и желания что-то делать с кодом. Если код для них понятен, естественно.

А никто и не обещал что код будет легко читаем и прост.
Когда после исходников САС начинаешь читать сторонние коды - так аж плакать хочется.

Да код сложный но при желании и умении все находится и делается. Vdemidov ни разу не проигнорировал вопросы по теме и не по теме.

Если переписать всё с нуля и на Си - это уже будет не САС-Планета.
//«Если все составные части исходного объекта были заменены, остаётся ли объект тем же объектом?» (с) парадокс корабля тесея



возвращаемся к топику

В эту тему давайте высказываться по двум вопросам:
1) как делать пулреквесты. Я их давно не делал и забыл совсем как их делать. Давайте сделаем инструкцию.

а) Делаем форк
б) Вносим изменения в свою копию.
в) Коммитим на сервер в свою копию.
г) Засылаем эти коммиты в основную ветку.
Ждём принятия или коментариев с указанием что не так.
В случае ошибок закрываем бранч, делаем новую ветку от текущей ревизии. повторяем с пункта "в"

2) насколько фраза "ждем пулреквестов" в реальности тормозит развитие программы...

Ни разу не тормозит. Если хотелка актуальная\нужная и интересная - или сделать просит много человек - не вопрос. Всё остальное ИМХО нельзя назвать развитием.
Ну кому нужна фича которой будет пользоваться 1 человек который о ней знает?
хотелок куча и не факт что все из них нужны http://www.sasgis.org/mantis/view_all_bug_page.php

[DJ VK]

возвращаемся к топику

В эту тему давайте высказываться по двум вопросам:
1) как делать пулреквесты. Я их давно не делал и забыл совсем как их делать. Давайте сделаем инструкцию.

а) Делаем форк
б) Вносим изменения в свою копию.
в) Коммитим на сервер в свою копию.
г) Засылаем эти коммиты в основную ветку.
Ждём принятия или коментариев с указанием что не так.
В случае ошибок закрываем бранч, делаем новую ветку от текущей ревизии. повторяем с пункта "в"

С разовыми "быстрыми" правками все более или менее ясно. Там ситуация еще бывает когда форк сделали, потом некоторое время делали правки, отлаживались. А основная ветвь успела обновиться. Как такое склеить?

p/s/ Но то чтобы абсолютно неверно, но все таки спорно, насколько хороша ситуация, когда взрослому программисту по ресурсам проще просить содействия разработчиков, чем самому освоить весь код программы и менять его как вздумается... Как насчет того, чтобы просто нарисовать иерархию классов проекта и описать за что каждый класс банально отвечает?

[vdemidov]

С разовыми "быстрыми" правками все более или менее ясно. Там ситуация еще бывает когда форк сделали, потом некоторое время делали правки, отлаживались. А основная ветвь успела обновиться. Как такое склеить?

Для этого есть операция rebase. А вообще есть вики, но кто же ее читает.

Как насчет того, чтобы просто нарисовать иерархию классов проекта и описать за что каждый класс банально отвечает?

Отличная идея. Быстренько нарисуйте, а мы, с удовольствием, подскажем те места, которые непонятны. Большинство названий классов и интерфейсов вполне позволяют догадаться о их назначении. А потом это нужно будет поддерживать в актуальном состоянии. Готовы?