Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
votes changed from to slavazanko
Статья хорошая. Примерно так мы и варимся.
My vote here :)
Статья хорошая. Примерно так мы и варимся.
My vote here :)
>Как ревизор получает правку для ревизии?
он видит на таймлайне сообщение о том что тикет на голосовании, также разработчик может посмотреть отчет о выставленных на ревизию тикетах
Так же разработчики постоянно находятся в jabber конференции и тот кому сильно невтерпеж может попросить в комнате отсмотреть бранч.
>У каждого разработчика свой репозиторий? Кто имеет право пушить в главную ветку?
все разработчики имеют на это право, главное чтобы бранч получил нужное количество голосов, был оформлен как положено. Первое время новому (можно назвать это стажировкой) разработчику помогают остальные коллеги, словом и делом.
>Какая связь/разница между апстримом, главной веткой, master'ом?
есть стабильная версия уже выпущенная и которая уже отпочковалась от «мастера» и которая зажила своей жизнью и есть «мастер» (он тоже условно стабильный). В теории стараемся придерживаться принципа что мастер это всегда готовая к релизу, рабочая версия (релизится как только разработчики решили — всё количество улучшений достаточно а критические ошибки найденные ранее исправлены в необходимом объеме)
>Что Вы называете патчем?
я имел ввиду не конкретное исправление а набор коммитов в бранче (их ведь всегда можно свернуть к одному ченджсету, это не делается чтобы был виден путь разработки и удобства аудита)
он видит на таймлайне сообщение о том что тикет на голосовании, также разработчик может посмотреть отчет о выставленных на ревизию тикетах
Так же разработчики постоянно находятся в jabber конференции и тот кому сильно невтерпеж может попросить в комнате отсмотреть бранч.
>У каждого разработчика свой репозиторий? Кто имеет право пушить в главную ветку?
все разработчики имеют на это право, главное чтобы бранч получил нужное количество голосов, был оформлен как положено. Первое время новому (можно назвать это стажировкой) разработчику помогают остальные коллеги, словом и делом.
>Какая связь/разница между апстримом, главной веткой, master'ом?
есть стабильная версия уже выпущенная и которая уже отпочковалась от «мастера» и которая зажила своей жизнью и есть «мастер» (он тоже условно стабильный). В теории стараемся придерживаться принципа что мастер это всегда готовая к релизу, рабочая версия (релизится как только разработчики решили — всё количество улучшений достаточно а критические ошибки найденные ранее исправлены в необходимом объеме)
>Что Вы называете патчем?
я имел ввиду не конкретное исправление а набор коммитов в бранче (их ведь всегда можно свернуть к одному ченджсету, это не делается чтобы был виден путь разработки и удобства аудита)
>Но Вы ответили только частично.
если так то извиняюсь… показалось что в полном объеме отписал :)
есть основной репозиторий он открыт для всех разработчиков на запись.
>А сам-то бранч — как получить?
ответственный за тикет выставляет бранч на обзор, об этом пишет в тикете
посмотрите в том тикете как это выглядит в #1746
разработчик который хочет отсмотреть код делает
собирает, смотрит что бранч соответствует заявленному.
далее смотрит код, при необходимости вносит свой код.
Делает комментарии по поводу кода в тиките
>Впрочем, из других ответов следует, что у Вас один репозиторий на всех (да?),
да, но под каждую проблему создается свой бранч, после утверждения он вливается в ветвь-родитель.
сторонние разработчики могут аттачить свои патчи в тикете или создать свою ветвь в стороннем репозитории например на github.com
если так то извиняюсь… показалось что в полном объеме отписал :)
есть основной репозиторий он открыт для всех разработчиков на запись.
>А сам-то бранч — как получить?
ответственный за тикет выставляет бранч на обзор, об этом пишет в тикете
branch: 123_name_branch changeset: sha_sum
посмотрите в том тикете как это выглядит в #1746
* owner set to bilbo
* status changed from new to accepted
* severity changed from no branch to on review
Created branch 1746_passive_mode_over_proxy
Initial changeset: b32c9e4a2a15cd50a6a07ad85b1a587328bd2cfc
разработчик который хочет отсмотреть код делает
git checkout -b 1746_passive_mode_over_proxy origin/1746_passive_mode_over_proxy
собирает, смотрит что бранч соответствует заявленному.
далее смотрит код, при необходимости вносит свой код.
Делает комментарии по поводу кода в тиките
>Впрочем, из других ответов следует, что у Вас один репозиторий на всех (да?),
да, но под каждую проблему создается свой бранч, после утверждения он вливается в ветвь-родитель.
сторонние разработчики могут аттачить свои патчи в тикете или создать свою ветвь в стороннем репозитории например на github.com
> НИКОГДА(!!!) не производить перебазирование (rebase) стабильной ветки относительно «master», чтобы объединить исправления!
> Обязательно произвести перебазирование своего бранча относительно родительской ветви.
> NB: Если не сделать перебазирование то возможна ситуация когда другие разработчики уже влили свои конкурирующие изменения в нашу родительскую ветвь, и в лучшем случае история в ней будет путанной и сумбурной, а в худшем — родительская ветвь перестанет собираться либо будет работать некорректно.
Поясните пожалуйста первый пункт. Что такое стабильная ветка?
> Обязательно произвести перебазирование своего бранча относительно родительской ветви.
> NB: Если не сделать перебазирование то возможна ситуация когда другие разработчики уже влили свои конкурирующие изменения в нашу родительскую ветвь, и в лучшем случае история в ней будет путанной и сумбурной, а в худшем — родительская ветвь перестанет собираться либо будет работать некорректно.
Поясните пожалуйста первый пункт. Что такое стабильная ветка?
я чуть выше написал про стабильные ветви.
Тогда поясните пожалуйста следующее:
> НИКОГДА(!!!) не производить перебазирование (rebase) стабильной ветки относительно «master», чтобы объединить исправления!
Почему этого нельзя делать?
> НИКОГДА(!!!) не производить перебазирование (rebase) стабильной ветки относительно «master», чтобы объединить исправления!
Почему этого нельзя делать?
за время прошедшее с момента выпуска релиза «master» успевает уйти сильно вперед и такой ребэйз просто убьёт ту стабильную ветвь…
Если я правильно понял, то имеется в виду, что нельзя в исправлении брать фиксы из ответвления к стабильной ветки — надо отращивать ветку исправления непосредственно от master, а перед публикацией — ещё и трансплантировать ветку с исправлением на ушедший вперёд origin/master.
Если понял неправильно, то присоединяюсь к просьбе о пояснении.
Если понял неправильно, то присоединяюсь к просьбе о пояснении.
Нельзя перебазировать ветку, которая объявлена как «стабильная» относительно мастера.
Стабильная ветка не содержит патчей с добавлениями фишек — только патчи с багфиксингом.
Развитие проекта продолжается в мастере, а в стабильную ветку периодически перетаскиваются стабилизирующие коммиты. В этом случае для переноса таких патчей с мастера нельзя в ветке сделать так:
git rebase origin/master
Потому что будут внесены все патчи! Для «точечного» внесения нужжно использовать 'git cherry-pick' или вручную вдумчиво переносить, если изменения между мастером и стабильной веткой стали большими.
Именно такая ситуация и имеется ввиду. И предупреждение об этом :)
Стабильная ветка не содержит патчей с добавлениями фишек — только патчи с багфиксингом.
Развитие проекта продолжается в мастере, а в стабильную ветку периодически перетаскиваются стабилизирующие коммиты. В этом случае для переноса таких патчей с мастера нельзя в ветке сделать так:
git rebase origin/master
Потому что будут внесены все патчи! Для «точечного» внесения нужжно использовать 'git cherry-pick' или вручную вдумчиво переносить, если изменения между мастером и стабильной веткой стали большими.
Именно такая ситуация и имеется ввиду. И предупреждение об этом :)
Возможность голосования встроена в Trac или это патч?
в тикете на Trac-е есть текстовое поле для того чтобы разработчики вписывали туда свои ники, последний проголосовавший определяет тикет утвержденным (если голосов достаточно).
на данный момент достаточно 2-х голосов, но иногда я например голосуя вторым мог бы сказать что тикет утвержден, но не делаю этого т.к. все работает, код я отсмотрел, но не на 100% уверен в коде, поэтому не утверждаю его, полагаясь на большую компетенцию следующего рецензента.
на данный момент достаточно 2-х голосов, но иногда я например голосуя вторым мог бы сказать что тикет утвержден, но не делаю этого т.к. все работает, код я отсмотрел, но не на 100% уверен в коде, поэтому не утверждаю его, полагаясь на большую компетенцию следующего рецензента.
Мы просто добавили новое поле.
trac.ini:
trac.ini:
[ticket-custom] ... votes = text votes.label = Votes for changeset
какая же классная штука когда коммиты сами закрывают тикеты «Fixes issue #123» и все дела, ибо возня с этими гигантскими гитовскими хэшами коммитов меня раздражает
Как бывший разработчик mc хочу поинтересоваться.
Каким образом вам удалось утянуть под себя исходники mc?
Насколько я помню, текущие мейнтейнеры были против,
Например вот тут
mail.gnome.org/archives/mc-devel/2009-February/msg00410.html
?????
Этой революцией вы оставили текущих разработчиков и мейнтейнера не у дел, фактически подмяв под себя проект.
Сейчас у нас были (уже не могу сказать что есть) патчи которые правили mc. Но применить их мы не имеем возможности.
Так как же так оказалось что проект был украден (не побоюсь этого слова) из рук разработчиков? Почему не захотелось работать наравне с другими, а захотелось подмять проект под себя?
Каким образом вам удалось утянуть под себя исходники mc?
Насколько я помню, текущие мейнтейнеры были против,
Например вот тут
mail.gnome.org/archives/mc-devel/2009-February/msg00410.html
?????
Этой революцией вы оставили текущих разработчиков и мейнтейнера не у дел, фактически подмяв под себя проект.
Сейчас у нас были (уже не могу сказать что есть) патчи которые правили mc. Но применить их мы не имеем возможности.
Так как же так оказалось что проект был украден (не побоюсь этого слова) из рук разработчиков? Почему не захотелось работать наравне с другими, а захотелось подмять проект под себя?
ну как бы Павел Цеков самоустранился, а Мигель был не против…
>Как бывший разработчик mc хочу поинтересоваться.
а почему не нынешний? что мешает?
>Почему не захотелось работать наравне с другими
ну почему же не захотелось то, хочется чтобы большее число разработчиков принимало участие в развитии. Другой момент что Павел по сути заморозил проект и даже самые минимальные патчи (в пару строк) просматривались им по году… Я его в принципе понимаю, сложно в одиночку все это тащить. А о переходе на UTF вообще речи не шло, так вот проект и висел с 2005 года практически без развития, я честно говоря думал он вообще умрет.
>Как бывший разработчик mc хочу поинтересоваться.
а почему не нынешний? что мешает?
>Почему не захотелось работать наравне с другими
ну почему же не захотелось то, хочется чтобы большее число разработчиков принимало участие в развитии. Другой момент что Павел по сути заморозил проект и даже самые минимальные патчи (в пару строк) просматривались им по году… Я его в принципе понимаю, сложно в одиночку все это тащить. А о переходе на UTF вообще речи не шло, так вот проект и висел с 2005 года практически без развития, я честно говоря думал он вообще умрет.
Мне показалось что Цеков был против. Кроме Цекова есть Павел Роскин, есть Андрей Самойлов, есть другие разработчики. Я тем, как изменилось все, был неприятно удивлен. Андрей тоже самое. Почему Цеков был против патчей? Он всегда обосновывал свою позицию — патчи были не лучшего качества. Потому как mc — кроссплатформенная вещь. А в данный момент я не знаю как ваш mc работает на всяких проприетарных unix-ах на которые в том числе работал Цеков.
Что мешает. Мешает пионерия. Когда я смотрел на патчи, которые вы вносили (сейчас не буду говорить — не слежу) в mc я заметил одну тенденцию: «Убираем код, который непонятен. Убираем предупреждения об ошибках, не устраняя эти ошибки». Например та же борьба с зависшим subshell-ом. В свое время Цеков предпринял целое исследование — как проблему с subshell порешать на всех платформах разом. И там не было прямого пути.
Ну были же другие проекты на базе mc. На лоре обсуждался mc который на базе ветки 4.1 развивали. Был еще проект на базе ветки 4.6 который тоже кто то русский пионерски патчил.
Кто вам мешал сделать ветку? ;) Ок. Даже если Мигуэль дал вам права — Цекова зачем было устранять и остальных? ;) Сосуществовали бы вместе. Что мешало?
Что мешает. Мешает пионерия. Когда я смотрел на патчи, которые вы вносили (сейчас не буду говорить — не слежу) в mc я заметил одну тенденцию: «Убираем код, который непонятен. Убираем предупреждения об ошибках, не устраняя эти ошибки». Например та же борьба с зависшим subshell-ом. В свое время Цеков предпринял целое исследование — как проблему с subshell порешать на всех платформах разом. И там не было прямого пути.
Ну были же другие проекты на базе mc. На лоре обсуждался mc который на базе ветки 4.1 развивали. Был еще проект на базе ветки 4.6 который тоже кто то русский пионерски патчил.
Кто вам мешал сделать ветку? ;) Ок. Даже если Мигуэль дал вам права — Цекова зачем было устранять и остальных? ;) Сосуществовали бы вместе. Что мешало?
скандалы… интриги… расследования…
Спасибо что подняли эту тему, действительно киллеры нынче дороги и на устранение Павла нам пришлось изрядно потратиться…
Цеков никоим образом не устранялся, точнее он просто прекратил общение и ушел, на письма, телеграммы не отвечает.
>Например та же борьба с зависшим subshell-ом. В свое время Цеков предпринял целое исследование…
видимо поэтому у нас ушло полгода на обсуждение этой проблемы :) прежде чем один хороший человек наконец его не запатчил…
И на последок один маленький вопрос… почему за целых полтора года (до появления Руфорка) небыло ни одного коммита в офф реп? если все так было зашибись? Но кажется я знаю ответ…
Спасибо что подняли эту тему, действительно киллеры нынче дороги и на устранение Павла нам пришлось изрядно потратиться…
Цеков никоим образом не устранялся, точнее он просто прекратил общение и ушел, на письма, телеграммы не отвечает.
>Например та же борьба с зависшим subshell-ом. В свое время Цеков предпринял целое исследование…
видимо поэтому у нас ушло полгода на обсуждение этой проблемы :) прежде чем один хороший человек наконец его не запатчил…
И на последок один маленький вопрос… почему за целых полтора года (до появления Руфорка) небыло ни одного коммита в офф реп? если все так было зашибись? Но кажется я знаю ответ…
> Мне показалось что Цеков был против.
Цеков был не против. Цекову было всё равно :(.
> Кроме Цекова есть Павел Роскин, есть Андрей Самойлов, есть другие разработчики.
Есть ещё список рассылки (mc-dev@gnome.org) в котором были дебаты. Пусть хоть из предыдущих разработчиков отпишется. Nobody cares :(.Вы один из предыдущих, и это замечательно :)
> Я тем, как изменилось все, был неприятно удивлен. Андрей тоже самое.
Знаете, я всегда говорил: «лучше просить прощения, чем разрешения».
Руководствуясь этим, хочу попросить у вас прощения за то, что было сделано. Это не подколка, нет никакого смысла между строк. Я, Занько Вячеслав, заваривший всю эту кашу, прошу у вас, бывших разработчиков прощения за свои действия. Заодно спрошу: согласны ли вы с тем, что мы используем имя Midnight Commander? Не подумайте — к имени не цепляемся. Более того — всем действующим разработчикам всё равно. Если Вы откажете — мы станем mc+ (Midnight Commander Plus) — и всего лишь.
> Почему Цеков был против патчей? Он всегда обосновывал свою позицию — патчи были не лучшего качества. Потому как mc — кроссплатформенная вещь. А в данный момент я не знаю как ваш mc работает на всяких проприетарных unix-ах на которые в том числе работал Цеков.
Честно говоря. не знаю тоже — нет абсолютно никаких вестей с этого фронта. То ли всё замечательно, то ли nobody cares. Ну и насчёт «против патчей»: можно годами шлифовать патчи в багтрекалке, но я предпочитаю пускать патчи «в оборот» для «обкатки». Этим самым снижается качество (неизбежно), но повышается скорость эволюции проекта.
> Что мешает. Мешает пионерия. Когда я смотрел на патчи, которые вы вносили (сейчас не буду говорить — не слежу) в mc я заметил одну тенденцию: «Убираем код, который непонятен. Убираем предупреждения об ошибках, не устраняя эти ошибки».
Да всякое бывало. В том числе и это.
> Например та же борьба с зависшим subshell-ом. В свое время Цеков предпринял целое исследование — как проблему с subshell порешать на всех платформах разом. И там не было прямого пути.
Вся эта борьба из-за раздельного промпта при включенных панелях и при выключенных. У меня есть мысля… пока смутная, но со светом в конце туннеля. Можно сделать единый промпт для панелей и сабшелла (для разных терминалов и для разных шеллов). Пока мыслю думаю :)
> Был еще проект на базе ветки 4.6 который тоже кто то русский пионерски патчил.
Этим пионером был я :)
> Кто вам мешал сделать ветку? ;)
Была ветка. Русский форк. Пионерия. как Вы выразились… я и не спорю — да было много смешного и нелепого, потому что были первые шаги. Но даже на такой проект народ налетел, как на пончики в базарный день. Знали бы вы, СКОЛЬКО было просто изголодавшихся и истосковавшихся по mc… сколько народу хотело есго дальнейшего развития, а не просмотра патчей годами (не примите как подколку… но тк и было :( ). При этом народ был не только русский — со всех концов света. Багтрекалка руфорка была русская (я планировал сделать национальный форк — типа междусобойчика). Но всё больше и больше появлялось тикетов с просьбами вести багтрекалку на английском… а также всё больше просьб вести разработку с именем Midnight Commander, а не как очередной форк.
> Ок. Даже если Мигуэль дал вам права — Цекова зачем было устранять и остальных? ;)
Да никто никого не устранял. :) «Невиноватые мы, он сам ушёл».
> Сосуществовали бы вместе. Что мешало?
Отсутствие интереса к существованию проекта у старой команды. Ничего личного. Констатация факта.
Цеков был не против. Цекову было всё равно :(.
> Кроме Цекова есть Павел Роскин, есть Андрей Самойлов, есть другие разработчики.
Есть ещё список рассылки (mc-dev@gnome.org) в котором были дебаты. Пусть хоть из предыдущих разработчиков отпишется. Nobody cares :(.Вы один из предыдущих, и это замечательно :)
> Я тем, как изменилось все, был неприятно удивлен. Андрей тоже самое.
Знаете, я всегда говорил: «лучше просить прощения, чем разрешения».
Руководствуясь этим, хочу попросить у вас прощения за то, что было сделано. Это не подколка, нет никакого смысла между строк. Я, Занько Вячеслав, заваривший всю эту кашу, прошу у вас, бывших разработчиков прощения за свои действия. Заодно спрошу: согласны ли вы с тем, что мы используем имя Midnight Commander? Не подумайте — к имени не цепляемся. Более того — всем действующим разработчикам всё равно. Если Вы откажете — мы станем mc+ (Midnight Commander Plus) — и всего лишь.
> Почему Цеков был против патчей? Он всегда обосновывал свою позицию — патчи были не лучшего качества. Потому как mc — кроссплатформенная вещь. А в данный момент я не знаю как ваш mc работает на всяких проприетарных unix-ах на которые в том числе работал Цеков.
Честно говоря. не знаю тоже — нет абсолютно никаких вестей с этого фронта. То ли всё замечательно, то ли nobody cares. Ну и насчёт «против патчей»: можно годами шлифовать патчи в багтрекалке, но я предпочитаю пускать патчи «в оборот» для «обкатки». Этим самым снижается качество (неизбежно), но повышается скорость эволюции проекта.
> Что мешает. Мешает пионерия. Когда я смотрел на патчи, которые вы вносили (сейчас не буду говорить — не слежу) в mc я заметил одну тенденцию: «Убираем код, который непонятен. Убираем предупреждения об ошибках, не устраняя эти ошибки».
Да всякое бывало. В том числе и это.
> Например та же борьба с зависшим subshell-ом. В свое время Цеков предпринял целое исследование — как проблему с subshell порешать на всех платформах разом. И там не было прямого пути.
Вся эта борьба из-за раздельного промпта при включенных панелях и при выключенных. У меня есть мысля… пока смутная, но со светом в конце туннеля. Можно сделать единый промпт для панелей и сабшелла (для разных терминалов и для разных шеллов). Пока мыслю думаю :)
> Был еще проект на базе ветки 4.6 который тоже кто то русский пионерски патчил.
Этим пионером был я :)
> Кто вам мешал сделать ветку? ;)
Была ветка. Русский форк. Пионерия. как Вы выразились… я и не спорю — да было много смешного и нелепого, потому что были первые шаги. Но даже на такой проект народ налетел, как на пончики в базарный день. Знали бы вы, СКОЛЬКО было просто изголодавшихся и истосковавшихся по mc… сколько народу хотело есго дальнейшего развития, а не просмотра патчей годами (не примите как подколку… но тк и было :( ). При этом народ был не только русский — со всех концов света. Багтрекалка руфорка была русская (я планировал сделать национальный форк — типа междусобойчика). Но всё больше и больше появлялось тикетов с просьбами вести багтрекалку на английском… а также всё больше просьб вести разработку с именем Midnight Commander, а не как очередной форк.
> Ок. Даже если Мигуэль дал вам права — Цекова зачем было устранять и остальных? ;)
Да никто никого не устранял. :) «Невиноватые мы, он сам ушёл».
> Сосуществовали бы вместе. Что мешало?
Отсутствие интереса к существованию проекта у старой команды. Ничего личного. Констатация факта.
>Сейчас у нас были патчи которые правили mc.
ну я думаю никто не потерял бы от того что вы бы их опубликовали бы в спуске рассылки либо в отдельном тикете на траке проекта.
> Но применить их мы не имеем возможности.
ведь в 4.6.x вы их можете применять…
ну я думаю никто не потерял бы от того что вы бы их опубликовали бы в спуске рассылки либо в отдельном тикете на траке проекта.
> Но применить их мы не имеем возможности.
ведь в 4.6.x вы их можете применять…
> уже не могу сказать что есть
Поэтому-то текущая команда и подхватила инициативу. Ваши патчи ушли в /dev/null из-за того, что работать с ними было невозможно. Приоритеты «разработки» предыдущей команды не вписывались ни в какие рамки, в результате в дистрибутивах были десятки патчей-подпорок, что бы mc можно было вообще хоть как-то пользоваться. Проблема проекта была в том, что эти патчи не управлялись SCM-системой, в результате ваши патчи сейчас ни к чему не применишь.
То, что есть сейчас — это колоссальный прорыв в развитии. Сколько лет у mc не было такой элементарной функции, как нормальная перекодировка? Сейчас она есть, включая utf8. Уже за это можно ребят поблагодарить.
Я не разработчик — времени нет, — но постоянно следил за развитием проекта.
git — это распределённая система: если хотите, можете отпочковаться и делать свой mc, и получать выгоду от обмена патчами (хотя это сложно, т.к. в текущий master входит много дебиановских патчей). А ещё лучше участвовать, т.к. если вы знаете, как устроены потроха mc, то вы можете принести пользу (хотя бы доку по потрохам «живыми словами» написать).
Поэтому-то текущая команда и подхватила инициативу. Ваши патчи ушли в /dev/null из-за того, что работать с ними было невозможно. Приоритеты «разработки» предыдущей команды не вписывались ни в какие рамки, в результате в дистрибутивах были десятки патчей-подпорок, что бы mc можно было вообще хоть как-то пользоваться. Проблема проекта была в том, что эти патчи не управлялись SCM-системой, в результате ваши патчи сейчас ни к чему не применишь.
То, что есть сейчас — это колоссальный прорыв в развитии. Сколько лет у mc не было такой элементарной функции, как нормальная перекодировка? Сейчас она есть, включая utf8. Уже за это можно ребят поблагодарить.
Я не разработчик — времени нет, — но постоянно следил за развитием проекта.
git — это распределённая система: если хотите, можете отпочковаться и делать свой mc, и получать выгоду от обмена патчами (хотя это сложно, т.к. в текущий master входит много дебиановских патчей). А ещё лучше участвовать, т.к. если вы знаете, как устроены потроха mc, то вы можете принести пользу (хотя бы доку по потрохам «живыми словами» написать).
Простите. Но, для вас коллосальный прорыв в развитии — это поддержка нормальной перекодировки?
И еще
Какие «Приоритеты «разработки» предыдущей команды» были? Озвучьте мне их пожалуйста?
Вы готовы ответить за новую команду mc? Я процитирую TODO от Роскина (кратко, какие ошибки надо исправить перед следующим релизом) и поглядим какие ошибки исправлены в текущем проекте?
И озвучьте плиз, раз уж влезли с защитой, нынешние приоритеты разработки?
И еще
Какие «Приоритеты «разработки» предыдущей команды» были? Озвучьте мне их пожалуйста?
Вы готовы ответить за новую команду mc? Я процитирую TODO от Роскина (кратко, какие ошибки надо исправить перед следующим релизом) и поглядим какие ошибки исправлены в текущем проекте?
И озвучьте плиз, раз уж влезли с защитой, нынешние приоритеты разработки?
если о TODO то
из глобальных вещей это
улучшения в порядком подтухшей самбе
улучшения fish
максимальная стабилизация кода
оптимизация по производительности.
в долгосрочной перспективе реализация плагинов.
из глобальных вещей это
улучшения в порядком подтухшей самбе
улучшения fish
максимальная стабилизация кода
оптимизация по производительности.
в долгосрочной перспективе реализация плагинов.
я скажу так то что было прорывом это UTF-8 на него ушли многие и многие часы разработки… остальное было уже вытекающим из этого.
И утф не в виде костыля как это было в патчах от дебьяна или федоры а нормальный утф после которого код не состоял бы из одних ifdef-ов, код который можно дальше развивать и сопровождать.
И утф не в виде костыля как это было в патчах от дебьяна или федоры а нормальный утф после которого код не состоял бы из одних ifdef-ов, код который можно дальше развивать и сопровождать.
> Какие «Приоритеты «разработки» предыдущей команды» были?
— Поддержка UTF-8
— Переопределение хоткеев
— устранение утечек памяти.
Устранение наиболее «болезненных» багов.
> Я процитирую TODO от Роскина
Да чего его цитировать? Вот оно: https://www.midnight-commander.org/browser/doc/TODO
> и поглядим какие ошибки исправлены в текущем проекте?
https://www.midnight-commander.org/query?status=closed&group=priority&order=priority&col=id&col=summary&col=type&col=priority&col=milestone&col=component&resolution=fixed
> И озвучьте плиз, раз уж влезли с защитой, нынешние приоритеты разработки?
— Стабилизация кода.
— Модульность. Как следствие плагины.
— Пересмотр и переделка VFS
— Большее использование glib-функций. Как следствие избавление от собственного дублирующегося кода => уменьшение размера исполняемого файла и упрощение сопровождения. Примеры: ской код по работе с ini-файлами (взятый когда-то с проекта wine) заменён вызовами соответствующих функций. Точно также с своими popt-функциями
— Поддержка UTF-8
— Переопределение хоткеев
— устранение утечек памяти.
Устранение наиболее «болезненных» багов.
> Я процитирую TODO от Роскина
Да чего его цитировать? Вот оно: https://www.midnight-commander.org/browser/doc/TODO
> и поглядим какие ошибки исправлены в текущем проекте?
https://www.midnight-commander.org/query?status=closed&group=priority&order=priority&col=id&col=summary&col=type&col=priority&col=milestone&col=component&resolution=fixed
> И озвучьте плиз, раз уж влезли с защитой, нынешние приоритеты разработки?
— Стабилизация кода.
— Модульность. Как следствие плагины.
— Пересмотр и переделка VFS
— Большее использование glib-функций. Как следствие избавление от собственного дублирующегося кода => уменьшение размера исполняемого файла и упрощение сопровождения. Примеры: ской код по работе с ini-файлами (взятый когда-то с проекта wine) заменён вызовами соответствующих функций. Точно также с своими popt-функциями
>> Какие «Приоритеты «разработки» предыдущей команды» были?
>— Поддержка UTF-8
>— Переопределение хоткеев
>— устранение утечек памяти.
>Устранение наиболее «болезненных» багов.
Простите, прочитал как «Какие предыдущие приоритеты команды были». :( Вот уж точно: каждый видит то, что хочет видеть. Приоритеты предыдущей команды описаны в TODO, линк на него есть в предыдущем посту.
>— Поддержка UTF-8
>— Переопределение хоткеев
>— устранение утечек памяти.
>Устранение наиболее «болезненных» багов.
Простите, прочитал как «Какие предыдущие приоритеты команды были». :( Вот уж точно: каждый видит то, что хочет видеть. Приоритеты предыдущей команды описаны в TODO, линк на него есть в предыдущем посту.
Для меня колоссальный прорыв в развитии — это банальное удобство. Когда мне не приходится сидеть с двумя разными окнами с разными локалями только для того, что бы одни документы смотреть в одной кодировке, а другие — в другой.
Приоритеты предыдущей команды, насколько я понял: суперстабильность и суперпортируемость (с последним у текущего mc плоховато — слишком большие были изменения).
Ответить, конечно, не могу — не разработчик. Для меня важно, что бы mc удовлетворял моим задачам работы с файлами, и всё. Что-то вроде «Make mc a CVS frontend comparable to Eclipse-3.0» из TODO Роскина мне совсем не нужно.
А так, задачи можно посмотреть в траке — и тут же и поучаствовать.
Приоритеты предыдущей команды, насколько я понял: суперстабильность и суперпортируемость (с последним у текущего mc плоховато — слишком большие были изменения).
Ответить, конечно, не могу — не разработчик. Для меня важно, что бы mc удовлетворял моим задачам работы с файлами, и всё. Что-то вроде «Make mc a CVS frontend comparable to Eclipse-3.0» из TODO Роскина мне совсем не нужно.
А так, задачи можно посмотреть в траке — и тут же и поучаствовать.
> Приоритеты предыдущей команды, насколько я понял: суперстабильность и суперпортируемость (с последним у текущего mc плоховато — слишком большие были изменения).
Плоховато или неизвестно? :)
Я знаю одну проблему: текущий mc не соберётся в текущем стабильном Cygwin из-за того, что в mc была добавлена поддержка IPv6 а в стабилном Цигвине её нет. Но и это решаемо в ближайшее время: mail.gnome.org/archives/mc-devel/2009-November/msg00048.html
На FreeBSD текущий мастер собирается, на [Open]Solaris тоже собирается (по мотивам https://www.midnight-commander.org/ticket/1749). Под Линукс — само собой.
Кто-то из нас вроде пробовал не так давно на OpenBSD собирать… или это была NetBSD? Не помню :)
За кадром AIX, HP/UX и т.д. Они «за кадром» не потому, что мы отказываетмся от их поддержки — были бы патчи :)
Плоховато или неизвестно? :)
Я знаю одну проблему: текущий mc не соберётся в текущем стабильном Cygwin из-за того, что в mc была добавлена поддержка IPv6 а в стабилном Цигвине её нет. Но и это решаемо в ближайшее время: mail.gnome.org/archives/mc-devel/2009-November/msg00048.html
На FreeBSD текущий мастер собирается, на [Open]Solaris тоже собирается (по мотивам https://www.midnight-commander.org/ticket/1749). Под Линукс — само собой.
Кто-то из нас вроде пробовал не так давно на OpenBSD собирать… или это была NetBSD? Не помню :)
За кадром AIX, HP/UX и т.д. Они «за кадром» не потому, что мы отказываетмся от их поддержки — были бы патчи :)
> > суперпортируемость (с последним у текущего mc плоховато — слишком большие были изменения)
> Плоховато или неизвестно? :)
> Я знаю одну проблему: текущий mc не соберётся в текущем стабильном Cygwin
Собственно, я сам и зафайлил эту проблему ( www.midnight-commander.org/ticket/371 ). :) А под cygwin 1.7 он уже собирается (в cygwin`овских анонсах нет)? Когда я последний раз проверял в июне — не получалось. Впрочем, я забросил попытки как раз из-за переходного статуса самого Cygwin: там была кривизна с библиотеками, в частности, с s-lang.
Ещё надо бы проверить на роутерах — я думаю, там будут те же проблемы, что и на cygwin. У меня в «олеговской» коллекции версия без поддержки utf8 (4.6.2). К сожалению, у меня нет настроенной кросс-системы, что бы самому попробовать.
> Плоховато или неизвестно? :)
> Я знаю одну проблему: текущий mc не соберётся в текущем стабильном Cygwin
Собственно, я сам и зафайлил эту проблему ( www.midnight-commander.org/ticket/371 ). :) А под cygwin 1.7 он уже собирается (в cygwin`овских анонсах нет)? Когда я последний раз проверял в июне — не получалось. Впрочем, я забросил попытки как раз из-за переходного статуса самого Cygwin: там была кривизна с библиотеками, в частности, с s-lang.
Ещё надо бы проверить на роутерах — я думаю, там будут те же проблемы, что и на cygwin. У меня в «олеговской» коллекции версия без поддержки utf8 (4.6.2). К сожалению, у меня нет настроенной кросс-системы, что бы самому попробовать.
> Собственно, я сам и зафайлил эту проблему
О как! Приятно пообщаться «вживую» (интерактивно), а не по-английки через комменты :)
Спасибо за багрепорт.
> А под cygwin 1.7 он уже собирается (в cygwin`овских анонсах нет)? Когда я последний раз проверял в июне — не получалось. Впрочем, я забросил попытки как раз из-за переходного статуса самого Cygwin: там была кривизна с библиотеками, в частности, с s-lang.
Гм… в свете сказанного: можно ли закрыть тикет как 'wontfix'? Вроде проблема и не наша… я уже думал сделать --enable-ipv6, но лень было да и не хотелось лишние #ifdef...#endif плодить. :)
О как! Приятно пообщаться «вживую» (интерактивно), а не по-английки через комменты :)
Спасибо за багрепорт.
> А под cygwin 1.7 он уже собирается (в cygwin`овских анонсах нет)? Когда я последний раз проверял в июне — не получалось. Впрочем, я забросил попытки как раз из-за переходного статуса самого Cygwin: там была кривизна с библиотеками, в частности, с s-lang.
Гм… в свете сказанного: можно ли закрыть тикет как 'wontfix'? Вроде проблема и не наша… я уже думал сделать --enable-ipv6, но лень было да и не хотелось лишние #ifdef...#endif плодить. :)
Вообще, конечно, cygwin — довольно полезная платформа, так что wontfix не надо. :) Я всё жду, когда они, наконец, допилят 1.7, тогда и попробую скомпилировать ещё раз.
Баг довольно сложный, т.к. затронуты сразу несколько команд. Но решаемый, я в это верю.
А с ipv6 проблем больше ни на каких платформах не возникало (на тех же роутерах)?
Баг довольно сложный, т.к. затронуты сразу несколько команд. Но решаемый, я в это верю.
А с ipv6 проблем больше ни на каких платформах не возникало (на тех же роутерах)?
>
Ещё надо бы проверить на роутерах — я думаю, там будут те же проблемы, что и на cygwin. У меня в «олеговской» коллекции версия без поддержки utf8
я писал oleo (мантейнер репозитария олеговского) он как то пробородил, а так есть под рутер с oleg's фирмваре как моя годичной давности сборка так и руфорк, и что то свежее…
wl500g.info/showthread.php?t=11483
ну и я как владелец белой коробочки регулярно на ней тестирую последний мастер.
Ещё надо бы проверить на роутерах — я думаю, там будут те же проблемы, что и на cygwin. У меня в «олеговской» коллекции версия без поддержки utf8
я писал oleo (мантейнер репозитария олеговского) он как то пробородил, а так есть под рутер с oleg's фирмваре как моя годичной давности сборка так и руфорк, и что то свежее…
wl500g.info/showthread.php?t=11483
ну и я как владелец белой коробочки регулярно на ней тестирую последний мастер.
а вот мне, как нынешнему пользователю mc, очень нравится что за него наконец взялись, ибо в каждом дистре была своя толпа из десятков патчей и еще справка и хинты были в какой-то дебильной кодировке, которая показывалась кракозябрами.
теперь же все пучком, видно что проект живет и развивается. если кому-то не нравятся изменения, то есть древняя заброшенная ветка 4.6, ее никто не отменил.
если уж на то пошло, то какие регрессии есть в 4.7 по сравнению с 4.6?
теперь же все пучком, видно что проект живет и развивается. если кому-то не нравятся изменения, то есть древняя заброшенная ветка 4.6, ее никто не отменил.
если уж на то пошло, то какие регрессии есть в 4.7 по сравнению с 4.6?
* Me запасся попкорном.
Легко ли исправлять ошибки в git репозитории и были ли прецеденты? Ну скажем кто-то сделал что-то, что не должен был сделать.
>ошибочно залитые коммиты?
за прошедший год я наблюдал 2 случая когда пришлось подчистить «master» от влитых по неосторожности некорректных коммитов. Но делалось это по горячим следам и никаких последствий не имело. Вообще такого в принципе быть не должно, но все бы люди и всем свойственно ошибаться.
Если речь идет о здоровье самого репозитария, то для его поправки есть опция в гите, но естественно речь о локальных копиях, пару раз запускал git fsck полечить свой локальный реп, т.к. часто ставлю (ставил по началу) бесчеловечные эксперименты. :)
за прошедший год я наблюдал 2 случая когда пришлось подчистить «master» от влитых по неосторожности некорректных коммитов. Но делалось это по горячим следам и никаких последствий не имело. Вообще такого в принципе быть не должно, но все бы люди и всем свойственно ошибаться.
Если речь идет о здоровье самого репозитария, то для его поправки есть опция в гите, но естественно речь о локальных копиях, пару раз запускал git fsck полечить свой локальный реп, т.к. часто ставлю (ставил по началу) бесчеловечные эксперименты. :)
несколько офтоп, но:
Ребята, спасибо вам за mc!
Ребята, спасибо вам за mc!
Блин, может хотябы какие-нибудь схематические иллюстрации добавили? Начинающему очень трудно разобраться будет в этой статье
Спасибо.
Понравилась идея именования веток с использованием номера задачи — стало гораздо яснее и проще выполнять задачи, потому что сразу видно номер задачи и не стремишься сюда пихнуть решение еще одной «вкусной».
Да и время жизни веток сократилось. До этого они жили долго и порой сильно уходили от корней.
p.s. применяем SVN, пока не удалось без граблей сделать экспорт в Git (
Понравилась идея именования веток с использованием номера задачи — стало гораздо яснее и проще выполнять задачи, потому что сразу видно номер задачи и не стремишься сюда пихнуть решение еще одной «вкусной».
Да и время жизни веток сократилось. До этого они жили долго и порой сильно уходили от корней.
p.s. применяем SVN, пока не удалось без граблей сделать экспорт в Git (
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Коллективная разработка с использованием git и Trac в проекте Midnight Commander