I am 100% for this move. Both to gitlab and regardless of gitlab, to a new infrastructure. I would add another plus... gitlabs CI/CD tools seem to be way better than phabs.
On Fri, Aug 10, 2018, 1:16 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > To list some pros and cons for a switch: > > PROS: > * Greatly improved patch review UI > Gitlab is similar in workflow and usage to Github, so it will be much > easier to use the patch review tools > * Simplified patch submission workflow > Gitlab uses git and does not require external tools such as arc/git-phab > * Actively developed > Phabricator is basically closed-source at this point, and they develop only > as they decide to or as people pay them to. Gitlab is open source and the > developers actively reply to tickets and fix issues > > CONS: > * Does require having people manage a migration > * Will take time to migrate > * Will take time to adjust to new tools/workflows > > On Fri, Aug 10, 2018 at 2:09 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > Hello, > > > > For some time now, everyone in the community has been expressing > > significant dissatisfaction with the current project management software, > > Phabricator. A number of individuals have proposed switching to Gitlab > for > > various reasons. > > > > Some will recall that recently all of the FDO infrastructure migrated > from > > Phabricator to Gitlab thanks in large part to an incredible, hand-crafted > > migration script authored by notable open source figure Daniel Stone. > While > > this script was not exactly what could be used to migrate our own > > infrastructure, it gave me an idea. > > > > Thanks to a low-pay intern who just graduated and whose name I don't > > recall, work began to modify the original FDO migration script and update > > it to handle various features exclusive to our usage of Phabricator. > Thanks > > to generous hosting provided by the basement of the intern's parents, I > was > > able to review the work as it progressed to see if it would be worth > > showing to the community. > > > > Weeks have passed, and now, thanks to many sleepless nights and long > > weekends that this devoted intern spent doing devops work, I was able to > > provide justification for more robust hosting and acquire a cloud service > > to host an official proof-of-concept for a Gitlab migration: > > > > https://gitlab-prototype.s-opensource.org/ > > > > Some notes: > > * This is read-only for now > > * User creation is disabled, don't bother trying > > * Issues with their comments have been imported > > * Patch submissions have been imported (the intern screwed up some of the > > early imports so there are a few patches without the diff inlined) > > - Comments on patch submissions cannot be imported because Phabricator > > has no API for retrieving comments on patch review > > * Wiki pages are not imported since some decision-making is required > > > > As is easily noticeable, not all projects have been imported by my > intern. > > Importing the repo takes some time on its own, and then running the > > migration script takes a variable amount of time on top of that depending > > on the size of the project (EFL was estimated to take 10+ hours to fully > > import). > > > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > > and so it is impossible to do a 1:1 copy unless we decided to stick > > everything onto a specific project. We would have to decide how we want > to > > do this. > > > > If we decided to switch to Gitlab, there would be a number of questions > > that need to be answered: > > Q: How do we migrate? > > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > > one-time migration of projects. This means we would at some point lock > phab > > and then begin migrating, likely over a weekend for the major projects > with > > the remainders being added later. > > > > Q: What happens to phab? > > A: We would likely want to keep phab in read-only mode for a while after > > the migration since all the migrated tickets/patches will provide links > to > > it. We can later evaluate if we need to keep it running. > > > > Q: Where would this be hosted? > > A: The provided link here is a cloud service which will be funded for the > > foreseeable future. At present I am very strongly opposed to hosting this > > anywhere on the existing EFL infrastructure since it has been impossible > > for anyone to get access to any part of the server or to have tasks > > reliably handled in anything but a random and notification-less manner. A > > community project cannot have infrastructure which is unable to be > > accessed, managed, or maintained by the community which is using it. > > > > Regards, > > Mike > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
