I am interested in helping with this project. I would also be very
interested in taking charge of a bug triaging team. and closing out
fixed bugs as well as this will give us a chance to have a clean tracker
with only open and valid bugs
On 2018-09-06 15:07, Mike Blumenkrantz wrote:
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
------------------------------------------------------------------------------
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
