Jump to content

Phabricator no longer actively maintained


Recommended Posts

I finally decided to install arcanist, but then I was reminded that Phabricator is not maintained anymore:

https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/

Does that have any implications for the https://code.wildfiregames.com/? I.e. is it still worth the trouble to install arcanist or are there plans to migrate to a different tool?

Link to comment
Share on other sites

Just recently looked at arcanist and thought it's trouble. Then came across https://gitlab.haskell.org/ghc/ghc/-/wikis/why-not-phabricator and have to say the section "one year of arc on #ghc" is a hilarious read. Not going to use it ever.

I think facebook took over maintenance of phab, not sure what their plans are yet. Guess little short term implications for wfg but a possible switch would be a good opportunity to migrate to git as well.

  • Haha 1
Link to comment
Share on other sites

2 hours ago, hyperion said:

 

I think facebook took over maintenance of phab, not sure what their plans are yet. Guess little short term implications for wfg but a possible switch would be a good opportunity to migrate to git as well.

I'd like to, but I have a yet to make a concrete migration plan.

  • Like 1
Link to comment
Share on other sites

1 minute ago, smiley said:

What exactly is so complicated with the migration?

It certainly isn't trivial. Whether to and where to split pyrogenesis and 0ad, strip build artifacts or tarballs from history, to exclude external libs etc are questions which need answers.

Well, I'd start with the infra. Setup test.git.wfg.com. Add some test repos, setup hooks wanted, like maybe fast-forward only or run linter/CI for example, reports like mail and what not and try to break it. Play with gitweb, trac and if you want something github alike maybe gitlab and try to break it. Then document the setup you like best (and wait for it to get shot at from all sides ;)). In the meantime others can think about the actual conversion of the repo.

Link to comment
Share on other sites

2 hours ago, smiley said:

What exactly is so complicated with the migration?

1) Server maintenance. Currently the only person who knows how to handle properly Phabricator is Itms. If tomorrow Phab breaks beyond repair and he is not available then we're in a pickle.

2) server performance, the windows and linux slaves are currently putting a big strain on the server forcing us to change disks almost every year.

3) Server migration. If opting out of Phab we'd ideally migrate the diffs, concerns and whatnot too so it can be shutdown instead of keeping it around like we did for trac because it was better that whatever Phab used.

4) What to migrate,we currently have one huge repo containing art, art_source, and ps/trunk, (git only mirrors the last tiny part. Should we do the engine split and have empires_ascendant a separate mod ? Where do you put gaia stuff, where do you put components, rmgen etc

https://trac.wildfiregames.com/ticket/5366

5) Where to migrate what. What do we do with the artifacts (do we keep versionning them ? How can we make it a breeze to download them like it is currently if you're using svn), and all the windows dlls which are currently a huge pain to build (maybe less when/if @hyperionsucceeds. As said previously should we strip them from the history to reduce the git size ? What about libraries ? Should we find a way to debundle everything first ? That could take years. What about source/tools should that be another repo ? (After all the lobby was moved out)

 

 

47 minutes ago, hyperion said:

Then document the setup you like best (and wait for it to get shot at from all sides ;)). In the meantime others can think about the actual conversion of the repo.

6) Having the agreement of the majority of the team would be nice too, svn is easier for artists and some devs like it as well. (Just to be clear I'm 100% for the git migration as it has been a major complaint over the years)

7) Fun one, who does it ? Do I stop everything else to come up with something ?

8) When do we do the switch ? Mid release ? During the next three months CF because people are in holidays and can't look at bugs ?

9) Jenkins migration. Do we keep jenkins, do we rewrite all the jobs?

----------

1 bis) Do we say what the hell and just use whatever is on github at the moment ?

 

https://trac.wildfiregames.com/ticket/1814

https://trac.wildfiregames.com/ticket/1819

https://trac.wildfiregames.com/ticket/1816

  • Like 3
Link to comment
Share on other sites

11 hours ago, Stan` said:

Do we say what the hell and just use whatever is on github at the moment ?

Alternatively import it into perforce or plastic, both proprietary versioning systems catering to game development primarily.

So, I suppose what to keep and what not to keep is the question here. I would guess ./binaries doesn't belong in source code anyhow.

Edited by smiley
Link to comment
Share on other sites

20 minutes ago, smiley said:

So, I suppose what to keep and what not to keep is the question here. I would guess ./binaries doesn't belong in source code anyhow.

I would guess that too, but there is some dependency between C++ and JS components (Not that much, but still, RallyPoints, Identity, Attack, possibly others)

And also you can't run the game without the mod mod.

20 minutes ago, smiley said:

Alternatively import it into perforce or plastic, both proprietary versioning systems catering to game development primarily.

https://www.perforce.com/blog/vcs/plastic-scm-vs-perforce (Obviously biased)

I suppose proprietary isn't great but since my initial plan was to move to github....

Whatever we choose it should make it easier for people to contribute, and I think git fits that description. It's not like we attract a lot of industry professionals anyway, and they might be more familiar with git.

 

Link to comment
Share on other sites

1 hour ago, Stan` said:

Whatever we choose it should make it easier for people to contribute, and I think git fits that description. It's not like we attract a lot of industry professionals anyway, and they might be more familiar with git.

To attract new people git, especially with github, seems like the way to go for me (and it also seems like the standard for open source project nowadays).

1 hour ago, smiley said:

perforce or plastic

never even heard of that..

Link to comment
Share on other sites

If I may throw my hat into the ring, I am always confused by the different locations of stuff (Trac, GitLab, GitHub, SVN, Phab etc.), all which seem to be used in some way for 0 A.D. I'm 100% sure that you experts had very good reasons to set everything up as it currently is. If you think about migration, maybe there is a slight chance to make the overall environment a tiny bit less complicated for newbies? As I've scraped only the tip of the iceberg of programming and everything involved, my reply here might be of little concern, though. Anyway, thank you so much for all the time and efforts that you put into this wonderful project over so many years. :heart:

PS:

Now that I can build from SVN (on Debian seems to be easier for me than on Windows), which other of the named tools should I get acquainted with first?

Edited by Ceres
  • Like 1
Link to comment
Share on other sites

23 minutes ago, Ceres said:

Now that I can build from SVN (on Debian seems to be easier for me than on Windows), which other of the named tools should I get acquainted with first?

Phab and arc(anist) are probably the most useful. Using git is not required at all when using svn.

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, maroder said:

never even heard of that..

It's pretty big in the game dev industry, not so much in everything else. If you have worked with any of the third party engines, you would have definitely came across those as stuff like git has no support or wonky support. Surprisingly, Unreal engine offers perforce and SVN instead of perforce and plastic as in the case with Unity. CRY has just perforce. All in all, Perforce is the git of game dev I guess.

However, these are primarily designed with non-programming game devs, mostly artists, in mind. And honestly, personally, I find git to be more intuitive.

Edited by smiley
  • Like 1
Link to comment
Share on other sites

1 hour ago, Ceres said:

(Trac, GitLab, GitHub, SVN, Phab etc.)

Welcome to legacy. :)

I am by no means an authority on the matter, but SVN is where the code resides (from almost the start of the project), Trac was chosen as an all-in-one development platform, for tickets, code reviews, wiki and such, then people migrated development to Phab (I must admit it _does_ ease reviewing), but kept the rest on Trac, somebody made a repo on GH and GL probably because it looked cool, but we don't use it (developers can use it though).

Maybe https://subgit.com/ is interesting?

  • Thanks 1
Link to comment
Share on other sites

15 hours ago, Stan` said:

2) server performance, the windows and linux slaves are currently putting a big strain on the server forcing us to change disks almost every year.

They also rebuild the engine for java script changes and stuff that isn't intended to be committed. A lot be cut if you wanted.

 

15 hours ago, Stan` said:

and all the windows dlls which are currently a huge pain to build (maybe less when/if @hyperionsucceeds

Remaining known issues are optimizer breaking the build and texture conversion (nvtt), then polishing.

 

15 hours ago, Stan` said:

svn is easier for artists and some devs like it as well

For me it's a major reason not to contribute as it doesn't respect author and only knows committer. If you are lucky enough there is a patch by: in the message and if less there is a concern stating it (the latter I consider unacceptable).

 

3 hours ago, Stan` said:

I suppose proprietary isn't great but since my initial plan was to move to github....

There is no need to move to github or even git to accept pull request, just devs willing to do review there and apply the patches. The only reason to migrate to github is lack of infra and infra personal.

 

Link to comment
Share on other sites

18 hours ago, Stan` said:

svn is easier for artists

Clarifying question: Is it tho?

What I experienced from the terrain update or the loading screen tips is that is impossible to include art easily into a patch. So you have to attach it as zip to the patch or send it on some other way to someone with commit access. Was it ever more straight forward?

Link to comment
Share on other sites

2 hours ago, hyperion said:

They also rebuild the engine for java script changes and stuff that isn't intended to be committed. A lot be cut if you wanted.

Indeed we could sed the svn status to see if we need to rebuild. We do need to have a test executable though.

2 hours ago, hyperion said:

For me it's a major reason not to contribute as it doesn't respect author and only knows committer. 

I did not know that, I've seen some cross people commits on Github and always wondered how they did it. 

2 hours ago, hyperion said:

There is no need to move to github or even git to accept pull request, just devs willing to do review there and apply the patches. The only reason to migrate to github is lack of infra and infra personal.

I agree. I think we're in the later case.

2 hours ago, Freagarach said:

somebody made a repo on GH and GL probably because it looked cool, but we don't use it (developers can use it though).

I think it's been there since before 2011 See

 

 

1 minute ago, maroder said:

What I experienced from the terrain update or the loading screen tips is that is impossible to include art easily into a patch. So you have to attach it as zip to the patch or send it on some other way to someone with commit access. Was it ever more straight forward?

Phab != SVN. The only way to upload images (or any binary really) with Phab is through arcanist.

The point with SVN is there are barely ever merge conflicts you don't really have to worry about your next commit doing a merge on the branch or whether you need to rebase, or pull before you push etc. It does everything for you. You can also only clone the public mod or any sub part of the repo without having to clone  the whole thing.

 

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

8 minutes ago, Stan` said:

The point with SVN is there are barely ever merge conflicts you don't really have to worry about your next commit doing a merge on the branch or whether you need to rebase, or pull before you push etc. It does everything for you. You can also only clone the public mod or any sub part of the repo without having to clone  the whole thing.

Ok makes sense. but still, for the most part that only applies to artist who have commit access, which to the best of my knowledge is at the moment: you :D

Link to comment
Share on other sites

6 hours ago, Stan` said:

I've seen some cross people commits on Github and always wondered how they did it. 

git-format-patch / git-send-email and then use git-am

 

5 hours ago, Stan` said:

Well switching to a different versionning system is about commit access too

Commit access isn't that important with git, Linus is the only committer for Linux ;)

Also easy to add back if desired. But better they push their changes to their own public repo and someone doing commits on a regular basis pulls from them (DVCS).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...