URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 47922
[ Назад ]

Исходное сообщение
"План открытия исходных текстов Launchpad. Статья о Марке Шаттлворте"

Отправлено opennews , 13-Янв-09 12:09 
"The Roadmap To An Open-Source Launchpad (http://www.phoronix.com/scan.php?page=news_item&px=Njk4Ng)" - доступен план (https://dev.launchpad.net/OpenSourcing) открытия исходных текстов Launchpad (http://launchpad.net/), web-ориентированной службы для обмена информацией между разработчиками различных программных проектов. Выпуск Launchpad 3.0, распространяемой в исходных текстах, намечен на 21 июля. Закрытыми останутся только несколько подсистем, специфичные для внутреннего процесса разработки в компании Canonical. Вместо них будут доступны более универсальные компоненты.


Также можно отметить публикацию в издании New York Times статьи "A Software Populist Who Doesn’t Do Windows  (http://www.nytimes.com/2009/01/11/business/11ubuntu.html?_r=1)" рассказывающей о Марке Шаттлворте и успехах Ubuntu.

URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=19758


Содержание

Сообщения в этом обсуждении
"План открытия исходных текстов Launchpad. Статья о Марке Шаттлворте"
Отправлено BigAlex , 13-Янв-09 12:09 
Вообще, Марк очень адекватно заявлял свою позицию почему исходники закрыты. Некоторые части launchpad и так с самого начала были открыты и разрабатывались на том же LP, вклад комьюнити в эти открытые части за все время стремится к нулю, т.е. как пилила их одна команда LP так и пилит. Опять же сравнение LP с SourceForge.net полностью корретно.

Ну теперь открывайте иходники OpenNET! Это же тоже проект о Open Source...


"План открытия исходных текстов Launchpad. Статья о Марке Шаттлворте"
Отправлено User294 , 13-Янв-09 14:38 
> Ну теперь открывайте иходники OpenNET! Это же тоже проект о Open Source...

1) Зачем вам исходники LaunchPad?И что, вы реально его юзать будете?На мое имхо как багтрекер он бестолков, да и как остальное достаточно неоднозначная штука.Хотя может в результате его как раз допилят до чего-то вменяемого? :)
2) Зачем вам исходники опеннет?Он такой один.И хорош он совсем не движком.Собственно затрудняюсь что-то позитивное сказать о движке сайта, его оформлении и так далее.Но опеннет хорош не этим.Он будет жить со всего лишь приемлимым оформлением и движком.А вот зачем такой движок кому-то еще я хоть убейте не понимаю - у остальных проблема при попытке сделать аналог будет вовсе не в движке(их готовых и на порядок более интересных как грязи).А в том чтобы на сайт кто-то ходил и чтобы на нем было столько же новостей, знаний и так далее.


"План открытия исходных текстов Launchpad. Статья о Марке Шат..."
Отправлено Аноним , 13-Янв-09 14:59 
>На мое имхо как багтрекер он бестолков

Наоборот, с ним поудобнее, чем с багзиллой, мантисом и траком работать.


"План открытия исходных текстов Launchpad. Статья о Марке Шат..."
Отправлено vitek , 13-Янв-09 16:07 
>>На мое имхо как багтрекер он бестолков
>
>Наоборот, с ним поудобнее, чем с багзиллой, мантисом и траком работать.

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


"План открытия исходных текстов Launchpad. Статья о Марке Шат..."
Отправлено Аноним , 13-Янв-09 17:34 
>объединить бы их как-нибудь, чтобы баги попадали по назначению

Можно привязать баг в launchpad багу в upstream'е, есть API для обмена комментариями с trac и bugzilla


"План открытия исходных текстов Launchpad. Статья о Марке Шат..."
Отправлено vitek , 13-Янв-09 22:43 
>>объединить бы их как-нибудь, чтобы баги попадали по назначению
>
>Можно привязать баг в launchpad багу в upstream'е, есть API для обмена
>комментариями с trac и bugzilla

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


"План открытия исходных текстов Launchpad. Статья о Марке Шат..."
Отправлено User294 , 26-Янв-09 05:43 
>Можно привязать баг в launchpad багу в upstream'е, есть API для обмена
>комментариями с trac и bugzilla

Хренли толку с этого API если при заполнении бага заполняющему подыграть триажерам не судьба из-за куцести формы ввода бага и общей убогости?Вот и клюют с 200 000 нерастриаженых багов.Понятное дело - если вы не на сто процентов уверены что баг именно вон в том пакете (а сколько юзеров могут уверенно ткнуть пальцем в бажный пакет - понятно) - какой либо хинт триажерам вы предоставить не можете.А багтрекер не горит желанием подыгрывать в выборе проблемного компонента.Поиск пакета в котором грабль есть?Так он таков что если вы не знаете наверняка что там ищете - никогда им то что надо и не найдете.А если знаете - нафиг юзать этот поиск вообще?Посему проблемы будут здорово раньше чем дело дойдет до API.Для начала недетские грабли будут с триажингом.Потому что когда нихрена не известно - триажер должен детально вчитаться в кучу килобайтов бага, часто запросить доп. инфо (заполнить которое багтрекер не подсказал, тогда как банальная багзилла запросто такое может) и прочая.Ну вот и висит у них 200 000 багов в триаже.


"План открытия исходных текстов Launchpad. Статья о Марке Шат..."
Отправлено User294 , 26-Янв-09 05:09 
>Наоборот, с ним поудобнее, чем с багзиллой, мантисом и траком работать.

Мде?Вот так сходу: если вы чего-то не знаете - оно вам не подскажет.Вообще!Не знаете пакет?Версию?Правильно - в итоге вами это заполнено вообще не будет.Добавив и без того перегруженым триажерам еще вагон геморроя при сортировке багов на ровном месте.Отличить инсталеж пакетов от видеоподсистемы может и относительный чайник.А вот как конкретно пакет инсталера или видеодрайвера называется и\или какая там версия юзверг может и не знать.При том указание хотя-бы категории могло бы заметно облегчить участь триажеров.Учтя их загруженность странно что в этом направлении все очень скудно.Тэги?Есть!Вот только на самом деле они выбираются из фиксированного списка.Что?Вы не видите этот список а видите только инпут-бокс?И даже не знали об этом поскольку это надо ртфмнуть где-то сбоку?И правда - дропдаун с допустимыми в энном проекте тегами сделать было не судьба.И вот так - везде.Выбор пакетов и поиск по ним?Геморройный донельзя.Если не знаете на 100.0% - без шансов, проще вообще не заполнять: ошибочно заполненое поле еще хуже чем незаполненое.

Ладно, хотим посмотреть кто и что делал с багом и почему.И тут все плохо - коменты отдельно, изменения статусов отдельно.Оригинально.Итого машинную работу - соотносить одно с другим делает в итоге сам юзер (багрепотер, програмер, триажер или кто там еще).А что, один timeline на всю деятельность с багом как у других - не комильфо?Ведь куда информативнее и понятнее и не надо отдельно грузить второй список.При подходе "единый timeline" при взгляде видны и коменты и кто, что почему и нафига с багом сделал.Вроде они даже хотели сделать именно так.Правда на хотении все и закончилось.

Да еще и скорость работы всего этого какая-то не ахтецкая - юзать такой трекер весьма геморройно в итоге.Мне как багтрекер - не понравилось.Да и как остальное - даже единого логина блин нет.Там аккаунт, сям аккаунт... приходится помнить вагон логинов к разным кускам этого добра.Чего всем так хочется ЭТО - мне не особо понятно.

Трак кстати как багтрекер мне не особо симпатичен.Вьюшка версий исходников и отличий - там хороша, да.Багтрекер там странный (они хотели скрестить trouble tickets system с багтрекером чтоли?Или почему баги надо называть тикетами?).Вики вообще какое-то дохлое.В общем много и хорошо и чтобы все и сразу не бывает - трак тому яркий пример.

Багзилла ... наверное наиболее вменяемый *багтрекер* из всего перечисленного.Как именно багтрекер свое дело вроде делает и даже особо не мешает процессу и его участникам.Иногда даже помогает (ну там значения полей запомнить\баги найти).Могло бы быть лучше?Конечно!Но в конечном итоге собственно трекинг багов (заведение, по возможности с максимальным количеством осмысленно заполненых полей и мониторинг дальнейшей жизни багов) в ней пожалуй получше чем в перечисленных(тут наверное можно поспорить, рассматривайте это как мою имху - не то чтобы я в восторге от багзиллы, но от других я еще менее в восторге обычно...).