TL;DR lets remove some bottlenecks here

Overall, I see a shift to using Arcanist as a necessity.

1. The current process for reviewing a patch submission is downloading the patch and reading the deletions / additions in what could only be described as the most verbose way one could review a patch. Using Differential, as ikey mentioned, alongside the Arcanist tool, will make the lives of us either by being able to more rapidly review patches, since we can do it without being taken out of the Phabricator experience, which'll enable the inline diffing, making deletions and inclusions more obvious, etc.
2. Arcanist's usage of git is in fact what most people would or could be doing already, just putting a simpler user experience over it. Their documentation in thorough however not as verbose as say Git SCM Book (which is good, to be honest, there has been many times I've linked the patch creation documentation and immediately people get lost). For example, arc diff will actually run `git merge-base origin/master HEAD..HEAD` by default, and you don't even need to do a git commit first, because it'll prompt you to create one if there are uncommitted changes.
3. You're still able to do bits like git commit amending via arc amend, making fixing changes before you push them easier.
4. Alongside all the server-side CI we'll be able to do, leveraging Conduit API, we'll actually have the ability to implement client-side linting, so we'll all be able to catch issues locally before we push them =)

Downside of Arcanist IMO: It's PHP. shudders

Other notes: I'm still uncertain how configuration itself works. I'm fairly certain it still requires a git config, but the documentation I saw initially wasn't completely clear.

On the point on having Phabricator manage our git repositories, I was initially skeptical about this (I am still, to a degree), however here are the immediate benefits I see:

1. Phabricator doesn't give a damn where the repository is hosted.. If desired, this could actually mean leveraging features and tooling on our own Phabricator to assist and improve projects we shepherd, such as Budgie Desktop repositories. From initial appearances, Harbormaster seems more simpler to use than git hooks directly.
2. We'll be able to curate who sees a repository, edit a repository, push to a repository, and more via Herald. I see this as extremely important for the independence of Solus as a project from third party infrastructure and can anticipate us being able to have private repositories like we do elsewhere.
3. We'll be able to refer to the repo using a callsign, like we do with tasks.
4. Diffusion has an API. That doesn't mean we'll need to use it, but we'll at least have the option to do so in the future.
5. We can change how fast we poll a repository via Phabricator or even manually do it. This is really great for watching for changes.

Gotta watch the packaging series on YouTube but becoming a maintainer of a few packages would pretty cool.

I am in

I'm in! It will be good learning experience..

For what it's worth, I find in 'maintaining' most of the things I've packaged, using RSS feeds make it a lot easier:

• https://github.com/user/project/releases.atom for Github
• https://sourceforge.net/projects/project/rss?path=/ for SourceForge

Might there be any way to feed things like that in?

@W-Floyd @DataDrake is working on an update system (he's talked about it previously in Sundays with Solus) so we won't need to manually track that stuff. Whether it'll tie into Phab, I don't know. In all likelihood it'll be a part of Solhub or a separate system.

In T2616#45286, @W-Floyd wrote:

For what it's worth, I find in 'maintaining' most of the things I've packaged, using RSS feeds make it a lot easier:

• https://github.com/user/project/releases.atom for Github
• https://sourceforge.net/projects/project/rss?path=/ for SourceForge

Might there be any way to feed things like that in?

@DataDrake is working on a solution for that IIRC

@JoshStrobl damn it :P

@cybre LOL

@JoshStrobl awesome, I'll be curious to see what you guys come up with :)

I'm in :)

Thanks for the feedback, all. I'm going to open a sub-issue for solhub.

For me, being new to Solus, it certainly would lower the entry barrier for creating patches.

Even though, learning how to create packages and patches properly is already on my todo for the weekend, and I consider (by looking through) that the description is "good enough", streamlining / standardizing the process is always a good thing to do.

For the con: "yet another tool", I do not really see this as an issue, since it would fit the workflow. I'm on the console already anyway, rather going into a browser to create the task / upload the patch etc. cuts the workflow.

@STiAT yeah that's sorta how I see it. It's more swapping one tool/mechanism for another. Plus the nicest thing for people will actually be when amending a patch, they can just
send the new one up immediately (arc diff --update) without going all the way around the houses again :)

I'm definitely interested in being a maintainer for more than the one package, And to be honest this setup would definitely streamline a lot of things once we get it implemented.

Obviously you can count with me! :D

I think it's pretty standard to have a git submission helper. OpenStack uses git-review for submitting to Gerrit. You could argue that hub is used for Github. And apparently arcanist is used for Phabricator (which is also written in PHP by the way). The only downside is that it appears arcanist needs packaging, which is really the only temporary con I see.

which is also written in PHP by the way

Yea, this was noted in my first comment.

the only temporary con I see

Wouldn't even call it a con, to be honest. Perfectly natural for these sorts of niche(r) tools to not be available (after all, we don't preempt requests), so we'll land it when we start the transition.

Hmh, what's the objection to PHP in this case except for adding the php depend on the build process?

Yea, it's PHP, but now having looked at the code base, that's not what most people think PHP is. It's actually very well structured and written, and pretty clean and sane code.

Hmh, what's the objection to PHP in this case except for adding the php depend on the build process?

I won't speak for @JoshStrobl, but for me at least there is something inherently cringe-worthy about using a language originally designed for dynamic HTML websites to write command line interfaces. Though I suppose the same could be said for Perl and that is well accepted to be a general purpose language these days.

Then again, it's also important to use the right tool for the job. Given that the Phab devs are mostly PHP-centric, I can't really fault them for not having multiple languages in the code-base. The cost of "context-switching" from one language to another while writing code is a real thing.

Okay, I probably didn't state the question wrong. Picking the right tool for the job - okay, but languages evolve. I just say Java, Python, Ruby... they were designed for other purposes they're used now too. And I'm far from a PHP fanboy .. rather the opposite.

Anyway, that was not my question. I wanted to know if there are any hard objections like php autoconfiguring into apache for people who didn't use php at the moment or similar side-effects. Everything else is just a programming language, and I couldn't care less to be true ...

Count me in. I would be happy to help with mantaining some packages if you find it appropiate.

In T2616#71560, @JoshStrobl wrote:

Seeing as we've since moved to Arcanist, this can probably be closed now :D

Regarding Arcanist you're right, but I somehow have a feeling that there is still a problem regarding people who want to help. Right now I have three commits for accepted package requests, that are waiting for over a month now. Are they not good enough, should they be tested more thoroughly?
On the other hand there are packages with fixed maintainers. I mean that makes sense and is good, but you can't see that from Arcanist. So imagine I see an old package, put hours of effort into building a package of the new version and finally submit it just to be told "Nah, I am the maintainer, revision abandoned".
I hope you can follow my thoughts and understand that this kind of kills my enthusiasm regarding Solus. I love it and I want to help, but I don't know how.