On 10/11/19 3:38 PM, Jano Svitok wrote:
>
> - gitlab issues are OK, but bugzilla is much more elaborate (for example
> allows custom fields and most of all, allows custom states -- gitlab flow
> and issue states is fixed! custom states have to be simulated using tags).
> I am not that familiar with wireshark bugzilla, but I suggest that someone
> that is familiar goes through typical workflows, and checks that all needed
> information can be stored in gitlab issues.
Is "elaborate" a good thing in our case? For example, searching closed bugs for arbitrary text is more difficult in BZ than it is in GitLab. As far as custom fields go, it looks like GitLab lets you set a template for issues[1], which should cover the information we currently require for new Bugzilla bugs. Documenting our different workflows is a great idea, and should be added to the Bugzilla and Gerrit gitlab-migration wiki pages.
> https://gitlab.com/wireshark/gitlab-migration/wikis/home seems to be in a
> private repo.
Fixed. Thanks!
> You may want to check cmake's gitlab instance:
> https://gitlab.kitware.com/cmake/cmake
This brings up something I've held off asking until now. What flavor of GitLab should we use? It looks like our options are:
- gitlab.com Free[2]
- gitlab.com Ultimate[2]
- Self-managed Free[3]
- Self-managed Gold[3]
GitLab offers Ultimate and Gold licenses for FOSS projects[4] at no charge, but I'm confused about what KitWare, KDE, and GNOME are using since they aren't in the OSS project list file[5].
[1]https://gitlab.com/help/user/project/description_templates#setting-a-default-template-for-issues-and-merge-requests
[2]https://about.gitlab.com/pricing/gitlab-com/feature-comparison/
[3]https://about.gitlab.com/pricing/self-managed/feature-comparison/
[4]https://about.gitlab.com/solutions/open-source/program/
[5]https://gitlab.com/gitlab-com/marketing/community-relations/gitlab-oss/blob/master/data/oss_projects.yml
