По договоренности с Владимиром Кочетковым я занялся изучением миграции с мантиса на google code Issue Tracker.
Пока остановились на следующей схеме:
1. Экспортируем баги из мантиса в xml файл (у мантиса для этого есть штатный плагин). Пример файла приведен в конце этого сообщения.
2. Заливаем баги в гугл с помощью Google Code Issue Tracker Data API, к которому есть .Net обертка (http://code.google.com/p/google-code-issue-tracker/)
API имеет ограничение — автор и дата создания бага всегда берутся текущие, т.е. перенести эту информацию из мантиса "один к одному" не удастся. Придется хранить ее в теле описания бага в каком то формате. Думаю в теле же стоит сохранить идентификатор оригинального бага — эти идентификаторы уже много где засветились (например в комментариях к коммитам), поэтому терять идентификаторы нельзя. Структура бага в гугле намного проще, чем в мантисе, многие атрибуты предлагается хранить в виде лейблов (приоритет, важность, компонент) или прямо в основном описании (шаги для воспроизведения, доп. информация).
Вот список всех атрибутов мантиса и описание того, как я собираюсь сохранить их в гугловом трекере: В виде лейблов (в мантисе эти атрибуты имеют небольшой список предопределенных значений):
<priority>
<reproducibility>
<resolution>
<severity>
<category>
В атрибуте "Status" (под статус в гугле заведен отдельный атрибут):
<status>
В заголовке:
<summary>
В основном описании:
<description>
<additional_information>
<steps_to_reproduce>
В основном описании, в виде дополнительных тэгов:
<id>
<date_submitted>
<duplicate_id>
<last_updated>
Также в виде тегов в основном описании. Значения этих атрибутов имеют случайный характер, а сами атрибуты были использованы очень редко, поэтому заводить под них лейблы думаю не стоит:
<build>
<os>
<os_build>
<platform>
Вот _полный_ список использования этих атрибутов:
build: 1132
os: Windows XP
os_build: 69
platform: CygWin
build: r6488
os: WinXP
os_build: SP2
platform: MS.NET 2.0
build: 6552
build: 6552
build: 0.9.3
os: ALTLinux
os_build: 3.0
platform: i686
profile_id: 2
build: May 2008 CTP build 0.9.4.8036
os: Windows XP SP 2
build: -r8391
Планирую игнорировать, как неиспользуемые в нашем мантисе:
<eta>
<fixed_in_version>
<profile_id>
<project_description>
<project_id>
<project_name>
<projection>
<sponsorship_total>
<sticky>
<version>
<view_state>
Всех пользователей из мантиса планирую завести как участников проекта — без этого назначить на них баги не получается. Как я уже написал выше, автором всех багов в гугловом трекере станет один аккаунт — тот, от чьего имени будет выполняться импорт багов. Думаю, что затем можно попробовать переназначить баг на истинного автора, а потом — на текущего овнера (если такой указан в мантисе).
Пример экспортированного xml:
Скрытый текст
<bug>
<additional_information>My additional findings on this issue.
1-) The types even can't be get from C#. Assembly.GetTypes(<above_assembly>) results in same exception for C#
2-) It doesn't happen if Method's accessor is public
3-) It doesn't happen if Derived takes only 1 generic parameter
4-) It emits such a code for derived class:
.override method instance void class ClassLibrary1.Base`1<!T>::Method()
C# won't emit above. And removing above IL code fixes the issue. So it look like an emitting problem to me.</additional_information>
<handler_email></handler_email>
<handler_id></handler_id>
<handler_realname></handler_realname>
<handler_username></handler_username>
<build></build>
<category>Compiler</category>
<date_submitted>05-11-10 17:08</date_submitted>
<description>The below code compiles fine. But you cannot reference it from another assembly.
public class Base[U]
{
protected virtual Method() :void
{
}
}
public class Derived[K,T]: Base[T]
{
protected override Method() : void
{
}
}
When you try you get error as :
Error: Method override 'Method' on type 'ClassLibrary1.Derived'2' from assembly 'ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' cannot find a method to replace..</description>
<duplicate_id>0</duplicate_id>
<eta>none</eta>
<fixed_in_version></fixed_in_version>
<id>1223</id>
<last_updated>05-11-10 17:10</last_updated>
<bugnotes>
<bugnote>
<id>2307</id>
<reporter_id>168</reporter_id>
<note>Assembly.GetTypes(<above_assembly>) will be => ref_to_above_assembly.GetTypes();</note>
<view_state>10</view_state>
<date_submitted>05-14-10 17:59</date_submitted>
<last_modified>05-14-10 17:59</last_modified>
</bugnote>
</bugnotes>
<os></os>
<os_build></os_build>
<platform></platform>
<priority>normal</priority>
<profile_id>0</profile_id>
<project_description></project_description>
<project_id>1</project_id>
<project_name>Nemerle</project_name>
<projection>none</projection>
<reporter_email>emperon@nospam.nospam</reporter_email>
<reporter_id>168</reporter_id>
<reporter_realname></reporter_realname>
<reporter_username>reverseblade</reporter_username>
<reproducibility>always</reproducibility>
<resolution>open</resolution>
<severity>major</severity>
<sponsorship_total>0</sponsorship_total>
<status>new</status>
<steps_to_reproduce></steps_to_reproduce>
<sticky>0</sticky>
<summary>Generic parameter and virtual/override</summary>
<version></version>
<view_state>public</view_state>
</bug>
А вот наши статусы:
Closed
Confirmed
Resolved
Assigned
New
Feedback
И статусы, и лейблы (те же приоритеты) расходятся с теми, которые гугл предлагает по умолчанию. Как думаете, может стоит по ходу импорта подменять наши статусы и лейблы на гугловые? Или просто перебить все гугловые на наши.
К сожалению мой тестовый проект на гуглкоде сейчас находится в рид-онли режиме, поэтому пока не могу скопировать сюда гугловые лейблы (
Здравствуйте, seregaa, Вы писали:
S>По договоренности с Владимиром Кочетковым я занялся изучением миграции с мантиса на google code Issue Tracker.
S>API имеет ограничение — автор и дата создания бага всегда берутся текущие, т.е. перенести эту информацию из мантиса "один к одному" не удастся. Придется хранить ее в теле описания бага в каком то формате. Думаю в теле же стоит сохранить идентификатор оригинального бага — эти идентификаторы уже много где засветились (например в комментариях к коммитам), поэтому терять идентификаторы нельзя. Структура бага в гугле намного проще, чем в мантисе, многие атрибуты предлагается хранить в виде лейблов (приоритет, важность, компонент) или прямо в основном описании (шаги для воспроизведения, доп. информация).
Трекер гугла умеет добавлять кастомные поля к issues, туда можно и автора и дату и старый ключ, навигация по ним будет вполне адекватной. Или это и есть лейблы?
Re[2]: Обсуждение: Переезд на Google Code Issue Tracker
Здравствуйте, Ziaw, Вы писали:
Z>Трекер гугла умеет добавлять кастомные поля к issues, туда можно и автора и дату и старый ключ, навигация по ним будет вполне адекватной. Или это и есть лейблы?
Да, насколько я понял, это лейблы и есть — набор слотов, в которые можно записать произвольную информацию.
Но хранить в лейблах совсем произвольную инфу имхо не очень хорошо, да и гугл ворчит на такие значения: "Note: You are using 3 uncommon labels".
А заводить предопределенное значение под каждого автора, дату или ключ — неправильно, все так лейблы предполагают более короткий список возможных вариантов.
С пользователями облом. Я попробовал добавить в проект пользователя testuser@testuser.com и назначиит на него багу. Это у меня получилось, и я планировал провести такой же трюк со всеми пользователями из мантиса. Но оказывается в проект можно добавлять только уже зареганные на гугкоде аккаунты, видимо по счастливой (???) случайности мыло testuser@testuser.com было уже зарегистрировано в гугле )))
Поэтому придется сохранить незарегистрированных в гугле авторов и владельцев в лейблах либо прямо в тексте бага.
В экспортированном из мантиса файле я насчитал 127 уникальных пользователей.
Экспериментирую с импортом. Завел в проекте виртуального пользователя, от имени которого создаю все баги и комменты. Реальных пользователей указываю в тексте багов. Пока получается примерно так:
IssueTrackerAPI не содержит методов для программной загрузки аттачей. Да и в xml файле, экспортированном из мантиса, сведений об атачах тоже нет.
Будем переносить аттачи руками? Их много?
Когда мы это дело обсуждали с Владом, то пришли к мнению, что закрытые баги переносить не стоит, т.к. мантис все равно останется доступен в виде оффлайн или онлайн-readonly копии. По идее, это отсеет большую часть пользователей мантиса, которые уже давно не активны.
По поводу вложений смогу посмотреть только завтра. Но не помню, чтобы я вообще их встречал в открытых багах
Здравствуйте, seregaa, Вы писали:
S>Как думаете, может стоит по ходу импорта подменять наши статусы и лейблы на гугловые?
Насколько я помню, у гуглокода на дефолтные метки и статусы завязан какой-то функционал, наверное лучше все же привести мантисовские к гугловским (добавив то, чего не хватает, но не изменяя гугловские).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>По поводу вложений смогу посмотреть только завтра. Но не помню, чтобы я вообще их встречал в открытых багах
Бывали и вложения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, seregaa, Вы писали:
S>IssueTrackerAPI не содержит методов для программной загрузки аттачей. Да и в xml файле, экспортированном из мантиса, сведений об атачах тоже нет. S>Будем переносить аттачи руками? Их много?
Вложения были, но может быть в импортированных записях просто оставлять ссылку на записать в прежнем багтреке?
И если вложение было, то до него добраться можно в любом случае.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Обсуждение: Переезд на Google Code Issue Tracker
Здравствуйте, seregaa, Вы писали:
S>Здравствуйте, seregaa, Вы писали:
S>Экспериментирую с импортом. Завел в проекте виртуального пользователя, от имени которого создаю все баги и комменты. Реальных пользователей указываю в тексте багов. Пока получается примерно так:
S>http://code.google.com/p/serjprojects/issues/detail?id=382&start=300
Все closed issues отображаются, не конвертить ли closed и resoved в fixed?
Re[2]: Обсуждение: Переезд на Google Code Issue Tracker
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, seregaa, Вы писали:
KV>Супер
KV>Когда мы это дело обсуждали с Владом, то пришли к мнению, что закрытые баги переносить не стоит, т.к. мантис все равно останется доступен в виде оффлайн или онлайн-readonly копии.
Мне не нравится такой перенос, было бы лучшим перенести всю информацию на гугл трекер, чтобы с мантиса слезть вообще.
Достаточно было добавить статус "Closed" в список "Closed Issue Status Values". После этого закрытые баги пропали из умолчального списка.
Хотя можно и подумать над конвертацией статусов.
Вот гугловый умолчальный список:
New = Issue has not had initial review yet
Accepted = Problem reproduced / Need acknowledged
Started = Work on this issue has begun
Fixed = Developer made source code changes, QA should verify
Verified = QA has verified that the fix worked
Invalid = This was not a valid issue report
Duplicate = This report duplicates an existing issue
WontFix = We decided to not take action on this issue
Done = The requested non-coding task was completed
А вот наш (стрелкой — вариант конвертации в гугловый статус)
New -> New
Feedback -> Feedback (без изменений)
Confirmed -> Accepted
Assigned -> Started
Resolved -> Fixed
Closed -> Verified
Здравствуйте, _nn_, Вы писали:
__>Скажем так
__>mantis-id: 46 (http://nemerle.rsdn.ru/bugs/view.php?id=46) __>mantis-submitted: 12-04-03 23:51 __>mantis-updated: 04-02-04 19:42 __>mantis-dublicate: 0 __>mantis-reporter: nazgul (Kamil Skalski) (А здесь аккаунт гугла) __>mantis-handler: olszta (Pawel Olszta) (А здесь аккаунт гугла)
__>Стоит еще завести таблицу перевода аккаунтов с мантиса на гугловский, чтобы все авторы багов были перенесены.
Ok, составлю таблицу соответствия гугловых аккаунтов (их сейчас 26) и пользователей мантиса (их сейчас 127). Для тех пользователей, для которых будет найдено соответствие, будет дана ссылка на гугловый аккаунт и они будут сделаны владельцами багов. Для остальных багов владельцем останется вирт аккаунт, а автор будет указан только текстом.
Здравствуйте, seregaa, Вы писали:
S>А вот наш (стрелкой — вариант конвертации в гугловый статус) S>New -> New S>Feedback -> Feedback (без изменений) S>Confirmed -> Accepted S>Assigned -> Started S>Resolved -> Fixed S>Closed -> Verified
По жизни чаще всего случается варианты:
New => Resolved и New => Feedback (т.е. WontFix)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
На сегодня утилита миграции готова, осталось только составить список сответствия пользователей мантиса и гугловых аккаунтов. Это позволит сохранить привязку багов к текущим владельцам (owner-ам). Поэтому, если кто то является владельцем багов в мантисе, но еще не имеет аккаунта в гугловом проекте — сейчас самое время попросить Влада или Владимира о создании аккаунта. Все равно это рано или поздно придется сделать, без этого дальнейшая работа над багами будет невозможной.
После создания аккаунта нужно сообщить здесь (ответом) или мне на почту свои имена в мантисе и гугле.
Вот текущий список (табом выделены установленные соответствия):
======================