Comments 41
Предлагаю в комментариях устроить перепись репозиториев программ, к разработке которых вы имеете непосредственное отношение.
ReactOS: github.com/reactos/reactos
ReactOS: github.com/reactos/reactos
Промоушн такой промоушн… :)
Я бы с удовольствием почитал, кто чем занимается.
Минусующим: а смысл «промоутить» ReactOS? Во-первых, Jeditobe и так всем и каждому уши прожужжал, во-вторых, это исключительно СПО проект, никакой коммерции нет.
Минусующим: а смысл «промоутить» ReactOS? Во-первых, Jeditobe и так всем и каждому уши прожужжал, во-вторых, это исключительно СПО проект, никакой коммерции нет.
Ну разве что бюджетных денег от разработки нормальных Linux'ов отвлечь.
Назовите, сумму которую ReactOS уже «отвлек».
А когда бюджетные деньги тратились на разработку Linux, там точно было целевое использование? Вспомним Пингвин Софтвер, различные юрлица Росы, как это все потом внезапно банкротилось. Может быть и не плохая идея, отвлекать деньги от такой «разработки» линуксов…
А когда бюджетные деньги тратились на разработку Linux, там точно было целевое использование? Вспомним Пингвин Софтвер, различные юрлица Росы, как это все потом внезапно банкротилось. Может быть и не плохая идея, отвлекать деньги от такой «разработки» линуксов…
UFO just landed and posted this here
Отличная статья, спасибо. От себя добавлю, что нормальные описания PR или Issue очень важны. Есть много статей о том, как правильно составлять баг-репорты, но я представляю идеальный баг-репорт так:
1. Суть проблемы;
2. Минимальный код для воспроизведения и описание окружения;
3. Текущий результат;
4. Ожидаемый результат.
Навскидку несколько свежих примеров неудачных репортов: 1, 2, 3. В одних информации слишком мало и приходится догадываться, а в других она не помещается на 3 экрана и желание вчитаться быстро пропадает. В действительности, чтобы найти золотую середину, достаточно задать себе несколько вопросов: «Этой информации достаточно для воспроизведения проблемы без фантазирования?», «Я оставил только тот минимум кода, который относится к проблеме и необходим для воспроизведения?».
1. Суть проблемы;
2. Минимальный код для воспроизведения и описание окружения;
3. Текущий результат;
4. Ожидаемый результат.
Навскидку несколько свежих примеров неудачных репортов: 1, 2, 3. В одних информации слишком мало и приходится догадываться, а в других она не помещается на 3 экрана и желание вчитаться быстро пропадает. В действительности, чтобы найти золотую середину, достаточно задать себе несколько вопросов: «Этой информации достаточно для воспроизведения проблемы без фантазирования?», «Я оставил только тот минимум кода, который относится к проблеме и необходим для воспроизведения?».
По поводу пункта 2 я раскрывал как-то тему: rmcreative.ru/blog/post/minimalnyy-testovyy-nabor. Если не ясно, почему возникает проблема, можно попробовать делить пополам: rmcreative.ru/blog/post/poisk-trudnovylovimoy-oshchibki-deleniem-popolam. В git для этого есть bisect.
SilverFire Спасибо, рад, что понравилось!
Я бы добавил как пример хорошего описания бага, на который недавно наткнулся, пример от SamDark
github.com/yiisoft/yii2/issues/8015
Я бы добавил как пример хорошего описания бага, на который недавно наткнулся, пример от SamDark
github.com/yiisoft/yii2/issues/8015
Добавлю свои 5 копеек: основная проблема с которой я столкнулся в Symfony — твои изменения могут дожидаться своего часа месяцами, отсюда начинаются все проблемы и пропадает мотивация учавствовать на регулярной основе.
согласен, такая проблема существует.
как я сам замечал, баги мержатся напорядок быстрее улучшений, естественно, чем серьёзнее баг, тем быстрее. Баги по безопасности по опыту в топе.
данные советы как раз и направлены на то, чтобы пул риквест был рассмотрен как можно быстрее и удачно смержен.
ведь для команды увидить хорошо составленный отчёт об ошибке, толковый пул риквест с тестами к нему — это только в радость.
как я сам замечал, баги мержатся напорядок быстрее улучшений, естественно, чем серьёзнее баг, тем быстрее. Баги по безопасности по опыту в топе.
данные советы как раз и направлены на то, чтобы пул риквест был рассмотрен как можно быстрее и удачно смержен.
ведь для команды увидить хорошо составленный отчёт об ошибке, толковый пул риквест с тестами к нему — это только в радость.
В любом крупном проекте найдется хорошая стопка issue или PR, которые висят месяцами или даже годами. Залипают обычно некритичные и часто сложновоспроиводимые проблемы, улучшения, сломы обратной совместимости, неоттестированные опасные PR. Рассматривая новый PR всегда перебираешь варианты: а нужны ли эти изменения, не дублируют ли они что-то существующее, не сломается ли чего, не зарыт ли тут слом обратной совместимости, придется ли менять документацию, и так далее.
Я раньше этого всего до конца не осознавал и сам думал «Блин, ну не уже ли нельзя смёржить то, ничего сложно нет», но после присоединения к Core-team начал невольно смотреть на это немного иначе. Каждый день — это поток изменений, комментариев, новых задач и PR. Случайные люди не видят этого, ведь кто захочет просто так получать 50+ уведомлений каждый день, и вчитываться в них и от всей души стараться решить чью-то проблему?
Я однажды услышал версию, что это происходит из-за плохо организованной работы в команде и если принудительно раздавать задачи и контролировать их исполнение — все будет чётко и быстро. Утверждение толковое, но в Open-source оно не будет работать. Какую бы задачу я не взял, займет она у меня 10 минут или 5 часов, я это буду делать добровольно, с удовольствием, целью помочь сообществу и за идею. Такое принудительно не работает.
Я раньше этого всего до конца не осознавал и сам думал «Блин, ну не уже ли нельзя смёржить то, ничего сложно нет», но после присоединения к Core-team начал невольно смотреть на это немного иначе. Каждый день — это поток изменений, комментариев, новых задач и PR. Случайные люди не видят этого, ведь кто захочет просто так получать 50+ уведомлений каждый день, и вчитываться в них и от всей души стараться решить чью-то проблему?
Я однажды услышал версию, что это происходит из-за плохо организованной работы в команде и если принудительно раздавать задачи и контролировать их исполнение — все будет чётко и быстро. Утверждение толковое, но в Open-source оно не будет работать. Какую бы задачу я не взял, займет она у меня 10 минут или 5 часов, я это буду делать добровольно, с удовольствием, целью помочь сообществу и за идею. Такое принудительно не работает.
Все верно и я это все понимаю. Но тут встает проблема разделения ответственности. Если core team не справляется, то надо делегировать ответственность. Сейчас получается так — сори, у нас нету на это времени, до ваших PR и issue мы дойдем нескоро.
То есть с одной стороны страдающая от нагрузки core team везде просит — помогите нам. С другой — извините, у нас нет времени на понять, а помогли ли вы нам.
Это путь в никуда. Если рост core team не будет успевать за ростом проекта — это беда.
То есть с одной стороны страдающая от нагрузки core team везде просит — помогите нам. С другой — извините, у нас нет времени на понять, а помогли ли вы нам.
Это путь в никуда. Если рост core team не будет успевать за ростом проекта — это беда.
Все-таки git делали инопланетяне. Сайт, понятный и удобный только на чтение.
Автор, друзья, коллеги, разработчики — не забываем про ответственность: habrahabr.ru/post/274791
С submitting issue более-менее понятно, а вот по code distributing просветите такой момент — улучшение необходимо придумать самому или можно связаться с автором проекта и он назначит тебе таск из своего todo списка?
По моему опыту работают оба пункта. Можно запросить roadmap проекта и выбрать таск самому.
Вполне можно взять что-то толковое из issue, но за что пока ещё никто не брался. В идеале если авторы проекта написали в issue что-то вроде «да, это круто было бы реализовать, но пока времени нет».
тут всё зависит от конкретной ситуации и может быть несколько вариантов.
часто бывает, что в обсуждении конкретного issue обсуждаются и идеи, как это можно исправить
например, как здесь github.com/yiisoft/yii2/issues/10218
в таком случае, обычно отправляется Pull Request с обсуждённым решением.
иногда люди, при отправке issue, сразу предлагают в описании возможное решение, в таких случаях, если решение хорошее, делается Pull Request на его основе.
но в большинстве случаев приходится самому приходится придумывать решение.
в больших крупных проектах (да и не в крупных тоже) я видел ситуацию, когда issue на github привязывались к таскам, например, в trello, где уже было их детальное описание.
но в общем и целом ситуация такова, что вы видите список issues на github и берёте из списка открытых, ни на кого не завязанных багов/улучшений и делаете для него Pull Request
часто бывает, что в обсуждении конкретного issue обсуждаются и идеи, как это можно исправить
например, как здесь github.com/yiisoft/yii2/issues/10218
в таком случае, обычно отправляется Pull Request с обсуждённым решением.
иногда люди, при отправке issue, сразу предлагают в описании возможное решение, в таких случаях, если решение хорошее, делается Pull Request на его основе.
но в большинстве случаев приходится самому приходится придумывать решение.
в больших крупных проектах (да и не в крупных тоже) я видел ситуацию, когда issue на github привязывались к таскам, например, в trello, где уже было их детальное описание.
но в общем и целом ситуация такова, что вы видите список issues на github и берёте из списка открытых, ни на кого не завязанных багов/улучшений и делаете для него Pull Request
Спасибо большое за статью. Как раз разбираюсь по теме, хорошо легла.
Рискую отхватить по карме, но тут знающая аудитория собралась и поэтому всё-таки спрошу про subtree (там ещё ссылка на первый вопрос есть). Буду очень благодарен за ответ.
Рискую отхватить по карме, но тут знающая аудитория собралась и поэтому всё-таки спрошу про subtree (там ещё ссылка на первый вопрос есть). Буду очень благодарен за ответ.
Как-то однобоко, честно говоря. Далеко не все проекты принимают pull request через github, у многих патчи принимаются исключительно через почтовую рассылку, а pull request на github не отключаются, и патчи висят годами, т.к. никто из разработчиков туда не заходит.
Вот, лучше бы об отправке патчей в рассылки рассказали, т.к. почтовые программы ломают патчи, требуют специальной настройки, и лучше всего настроить git на отправку email через send-email.
Вот, лучше бы об отправке патчей в рассылки рассказали, т.к. почтовые программы ломают патчи, требуют специальной настройки, и лучше всего настроить git на отправку email через send-email.
Удобнее всего прикладывать патч как вложение. Работает с любым клиентом, и ничего не ломается.
У меня Thunderbird ломал даже патч во вложении. Не всем удобно принимать вложение.
Аналогично Thunderbird, до сих пор никто не жаловался. Почему неудобно? Большинство программ отображают такие вложения сразу после тела сообщения.
Вот, например, пожелания разработчиков Wine:
Вот, например, пожелания разработчиков Wine:
The git send-email command is strongly recommended, but if you can't get it to work, you may send the patch file as an attachment. Remember to only attach one patch per email and use the subject line from the patch file as the subject line in the email. Also, always send your emails as plain text, not HTML or rich text.
А ещё мир гитом не ограничен. Убунтовские поделки практически все лежат на launchpad и используют bazaar.
Еще очень удобно в сообщении коммита делать референс на issue с которым он связан, как показано здесь. Тогда, при мерже кода в ветку по умолчанию, те issue, которые исправляет ваш pull request, будут закрыты автоматически.
Не освещен сценарий вендоринга, в котором Pull Request отклонен но правки необходимы вам для собственного проекта. Ветку со своими изменениями вы тогда вовсе не намерены удалять, и желаете еще поддерживать актуальной.
Влить ветку в свой мастер и иногда синхронизировать с апстримом. Делов-то.
Тонкость в том, что мержить нужно на локальной машине, а потом пушить на свой форк на хабе. Я например не сразу понял что только так и можно, github у себя эту операцию не делает.
Это не тонкость. Это документированное поведение. Не нужно ждать, пока снизойдёт озарение, достаточно прочитать брошюрку.
Ну и у локального репо должны быть два remote, тоже тонкость. И да, документированное поведение, так и статья не про rocket science. Хорошая статья, про документированное поведение. Вендоринг распространенное явление, чаще чем коммиты в апстрим.
локального репо должны быть два remoteВ любой книжке по гиту есть разбор случая, когда вообще нет центрального сервера. Разработчики делятся изменениями прямо из своего локального репозитория напрямую. Итого у нас не 2 удалённых репозитория, а столько, сколько разработчиков в команде. Опять же это не тонкость. Это нормальное поведение гита, для этого, собственно, он и разрабатывался.
А вообще можно же сделать PR самому себе. Тем самым смержив ветки на стороне github.
Не хотелось бы начинать холивар, но почему rebase, а не merge? После того, как вы выложили свою ветку в общий доступ (сделали PR) rebase может очень сильно навредить тем, кто решит взять напрямую ваш PR.
Sign up to leave a comment.
Как правильно внести свою лепту в Open Source проект: простые подсказки