Hello community, After a few months of manually migrating projects we have moved already over 60, most of them were core modules to make sure the most important projects were migrated before the mass migration happens. We are now at the point where a mass migration makes more sense than continuing handling migrations one by one, in part also because of the increasing amount of requests.
*Proposed plan and timeline for mass migration* - Projects that want their bugs migrated will create an issue in our infrastructure similar to this <https://gitlab.gnome.org/Infrastructure/GitLab/issues/172> over the next two months. These project bugs will be migrated to GitLab issues between June 1st and June 15th 2018. [0] - Individual projects that it's important for them to move to GitLab sooner (i.e. GSoC projects, core modules, etc.) can still do so with the same procedure as before. Feel free to ping me regularly about those. - Projects that doesn't create an issue for bug migration will migrate only the repository, also by June 1st 2018. - Projects that didn't opt in to migrating bugs can still do so while Bugzilla is not phased out, however timing will be different and the issues will be migrated in batches once every two months or so. - Bugzilla will only allow comments by June 1st 2018. Reporting new bugs on Bugzilla will be disabled. New issues will be reported and managed in GNOME's GitLab. - Bugzilla will be phased out and much likely converted into a static website by February 2020 (the proposed date may vary as we're still evaluating all the possible solutions to make sure all the bugs will remain available in read-only mode after Bugzilla's service decommission). We'll still evaluating possible ways of keeping old bugs available for historical reasons. - Cgit will be phased out and removed by June 1st 2018. The goal is to have all GNOME projects moved to GitLab by GUADEC 2018; I left some time for eventual issues between 15th June and 6th July. If you are a maintainer and you consider some issue in the migration process or GitLab itself a big problem for your project, please take a look if we are tracking it already in the upstream priorities for GNOME <https://gitlab.com/gitlab-org/gitlab-ce/issues/43566>. If we do so, consider those are ongoing effort items and hopefully there will be some progress in the upcoming months. If we don't track it, either create an issue in our infrastructure (preferred, so others can comment too) with the link to the upstream report or contact me in IRC or email and we can discuss if it should be considered part of our GNOME priorities. Feel free to share your thoughts and comments about the proposal and I hope the timeline fits well with your activities. *General update* - GitLab worked upstream <https://gitlab.com/gitlab-org/gitlab-ce/issues/22292> on *being able to rebase and modify non-dev* (from forks) MR/branches as we requested recently and the feature will be available on the 22nd of this month. Let me share our thanks to them for taking quick action. - Issues with *login/register raising 500 errors *due to Google's ReCAPTCHA are now fixed. - Amazon AWS for *CI on-demand* is set up and available to use, CI should be fast and scalable. This is being possible thanks to the help of sponsors, stay tuned for the actual announcements. [0] This is because it's not feasible to migrate all the issues from Bugzilla for several technical details, and from what we experienced with other projects the migration of bugs don't achieve as much as was thought. Projects can take this as an opportunity to start using new features of GitLab to be more efficient towards issue management.
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
