We've had some great feedback in this thread, but this is a big decision and there are still a number of key people who have not replied, making any sort of transition infeasible at this time.
As for who is doing migration: I am willing to help with this and teach people everything that is needed for migration/setup. This does not, however, mean that I will handle it all by myself; I am not a primary driver for switching off phabricator--though I do think it is objectively worse than gitlab for many things--I am just the guy who put together some script modifications and spent 5 minutes setting up a cloud instance. On Wed, Sep 5, 2018 at 8:11 AM Stefan Schmidt <ste...@datenfreihafen.org> wrote: > Hello. > > I can't find answers to my questions raised in this reply. > > As I just had a private conversation with q66 on the potential move let > me ask one core question again. > > Who is driving this transition and doing the work to get it all deployed? > > People seem to be under the impression it would be you or your intern, > but I never heard a confirmation on this. If any of the supporters in > this thread want to step up and driving this now would be a good time. > > regards > Stefan Schmidt > > > On 09/04/2018 05:45 PM, Mike Blumenkrantz wrote: > > I've uploaded the script from my intern here: > > https://git.enlightenment.org/devs/zmike/bztogl.git/ > > > > In the event that anyone is interested in using this script on a > different > > gitlab instance (which can be trivially set up locally using the official > > community edition gitlab docker image): > > * have phabricator api token > > * have gitlab api token > > * import project repository using gitlab web interface > > * edit L760 of bztogl/phabtogl.py to point to gitlab instance > > * run example: phabtogl --token $gitlab_token --target-project efl/efl > > --project efl --callsign EFL > > - script may stall and need to be run a few times per project > > > > Feel free to commit any changes to the script directly to this repo. > > > > On Thu, Aug 30, 2018 at 5:28 AM Stefan Schmidt < > ste...@datenfreihafen.org> > > wrote: > > > >> Hello. > >> > >> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: > >>> > >>> https://gitlab-prototype.s-opensource.org/ > >> > >> Thanks to the intern without name to get a real PoC out for this. > >> While people have advocating for such a move no one before her/him spent > >> the actual time to get this demonstrated! > >> > >> This will help us to understand the details of a potential move way > better. > >> > >>> > >>> Some notes: > >>> * This is read-only for now > >>> * User creation is disabled, don't bother trying > >>> * Issues with their comments have been imported > >> > >> Cool > >> > >>> * 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 > >> > >> That is a bit of a pity. One could think of scraping the original > >> diffusion web pages for the comments. Not sure if it would really be > >> worth the effort spent on a script doing that. > >> > >> If we are able to clear out our patch queue enough this issue would > minor. > >> > >>> * 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). > >> > >> As a first demonstration this helps already. If the community wants to > >> go this way we can have further steps where we import more projects and > >> check for consistency and sanity. I would expect there would be several > >> of such cycles before we are happy and would make a final switch > >> > >>> 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. > >> > >> Hmm. The way we used the phab wiki was really for the overall community > >> and not individual projects. Having said that I would think that most of > >> the wiki pages could be attached to efl, EFL or Terminology. The rest > >> will most likely be pages on process (commits guidelines, releases, etc) > >> > >> There will also be a ton of outdated pages which could simply be > removed. > >> > >> In the end we would need to go through all of them and decide what to > >> do. e.g move process docs into dokuwiki, remove outdated ones, move to a > >> specific project. > >> > >> If we should do this sortign before or after me moved all pages over I > >> am on the fence. It would be cleaner to only import the sorted pages but > >> that can delay the move for some time. > >> > >>> 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. > >> > >> As written above I would expect that we would have more trial runs on > >> the migration while fine tuning the script and reviewing the results. If > >> we are happy with what we have for a project we could lock it for a > >> weekend and move the projects over. > >> > >>> 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. > >> > >> With all the reference to tickets and differentials we might need keep > >> it around read only for a long time. The alternative would be to have > >> all the old issues and differentials imported as well and have a > >> re-write mapping for the links in our http server. Not very attractive > >> either. > >> > >>> Q: Where would this be hosted? > >>> A: The provided link here is a cloud service which will be funded for > the > >>> foreseeable future. > >> > >> This is a crucial point here. Business decisions change and the > >> community has no influence on this. With my community hat on I > >> appreciate that there would be a sponsoring of a cloud service, but I > >> truly think we should not depend on this mid or long term (having it run > >> there for a few month of migration would not worry me). > >> Even if it would be more paperwork having the sponsorship going to the > >> foundation and the service being paid out from there would be the right > >> way. We can acknowledge the sponsorship on our sponsors page. > >> > >> regards > >> Stefan Schmidt > >> > >> > >> > ------------------------------------------------------------------------------ > >> 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 > > > > > ------------------------------------------------------------------------------ > 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
