Page MenuHomeSolus

Making Contributing to Solus Easier
Closed, ResolvedPublic

Assigned To
Authored By
Feb 16 2017, 5:03 PM
Referenced Files
"Like" token, awarded by euoar."Like" token, awarded by kyrios123."Like" token, awarded by Riokei."Like" token, awarded by jtflynnz."Like" token, awarded by userdisabled20062021."The World Burns" token, awarded by ZachBacon."Like" token, awarded by baimafeima."Like" token, awarded by BennZoid."Love" token, awarded by taaem."Love" token, awarded by GladOSkar."Love" token, awarded by feskyde."Like" token, awarded by theSoenke."Like" token, awarded by curantes."Like" token, awarded by shameempk."Like" token, awarded by SFaulken."Like" token, awarded by cybre.


This is actually more of a public discussion, but..

I feel the patch process and disconnect between various elements of Solus is too much of a pain in the backside for most people.
I'm proposing that we basically fold all of our development "bits" into Phabricator.

As such, we'd expose our git repositories through Phabricator. Instead of using git format-patch HEAD~1 and then creating a new task, and then uploading it...
We'd use arcanist (arc) which is a CLI tool for working with Phrabricator. This allows uploading your changes directly to a new task automatically and it is then
associated with a repository. Additionally, it allows inline patch review, syntax highlighting, etc. Proper experience.

It does mean "yet another tool", but it does mean more streamlined integration. Additionally we could create repos at the push of a button and assign owners
from the community (you guys!). And no more downloading bleedin' .patch files. Also much like GitHub you can autoclose issues by mentioning them when
a patch is merged, all git activity will appear on this site, etc.

We'd also change the current build script to interact with Phabricator and report success/fail for patch merges.


  • Integrate all the things
  • Centralised dev portal
  • Easier for people to get involved and then everyone can contribute straight away


  • Yet another tool, slight change in workflow

Additionally from my side, I'll change how the repo is indexed so there is no need to wait between builds, and we can just keep pushing.

Last but not least, we're looking to you guys, the guys helping us fix and build Solus. You're doing fantastic work, so, are there any
among you who wish to become Solus maintainers?

Thanks in advance!

Event Timeline

TL;DR lets remove some bottlenecks here

cybre rescinded a token.
cybre awarded a token.

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'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:

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.

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

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

@DataDrake is working on a solution for that IIRC

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

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

Unknown Object (User) added a subscriber: Unknown Object (User).Feb 17 2017, 9:53 AM

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.

Unknown Object (User) added a comment.Feb 19 2017, 11:02 PM

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.

Unknown Object (User) added a comment.EditedFeb 20 2017, 12:34 AM

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 ...

DataDrake triaged this task as Normal priority.Apr 20 2017, 2:31 PM

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

JoshStrobl claimed this task.

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

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.