Yea I think it will be easiest to host this on the same server that's running we.phorge.it. If we're able to build it as an extension application for phabricator it can be setup in the same installation and then we can route the web server to host it properly.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 16 2021
Jul 15 2021
If it's not worthwhile then let's not do it
Jul 14 2021
nit-pick: maybe name them phabricator/master and phabricator/stable.
I'm fine with whatever naming
Jul 13 2021
I was discussing with @deadalnix a bit and I think it would make sense to retain branches in our fork that represent the master and stable branches from upstream, but not be the primary branches we commit/land phorge into. That would allow us to keep synced with upstream's changes and regularly merge those in. I think operating in this way would also let us be a little more flexible with allowing other changes to be worked on and landed in the phorge branches without being blocked by the rebrand changes. Then at some point in the future the rebrand changes would come in from the upstream branch, merge in, and we could make an official Phorge release.
Jul 12 2021
The future plans for the domain landing page are under T15008: Build Welcome Site. I'll close this out for now since the redirect is working.
I think it makes sense to host repositories here. If we go with monorepo what would general permissions be for something like that?
It looks like all @20after4 has to do is land that change into the upstream as it's approved. It might be better to have it land upstream then we pull in changes from upstream (there are a number of changes this fork is now behind on)
Jul 11 2021
Thanks for pointing this out. I updated the link to the correct one. Somehow an extra hyphen appeared in the URL which I swear I had copied directly from the page.
Hm I tried updating the nginx configuration to do a temporary redirect to https://we.phorge.it but it doesn't seem to be functioning properly. Someone else with better nginx experience might need to lend a hand -- @Matthew maybe?
Jul 10 2021
Are we supposed to make a similar lengthy statement?
Heh, I wasn't really sure what people were expecting so just wrote up some stuff to explain who I am and what my role will probably end up being.
Jul 8 2021
After agreeing and signing the document I submit myself here as a core team member, officially.
@jupe thanks for pointing out the typo, I've updated to fix that.
There's a lot of work to be done here. I've been coordinating with upstream to find a solution, though EvanP has indicated that we should probably take a few swings at solutions to see what does or doesn't work out. I've been out for the past week on holiday so I haven't made any recent progress.
Jul 7 2021
Thank you @cark, I reached out to James Daniel.
Thanks for creating this. I think there have been some notes in comments that mention having to make several updates
I think in the case of email headers we would want to duplicate the headers to allow sites migrating time to update their dependence on the existing email headers -- so duplicate the headers to include both X-Phabricator-XYZ and X-Phorge-XYZ, then in a year or so remove X-Phabricator-XYZ. I'm not sure if HTTP headers would be used the same way and might be possible to change those without a migration period.
I've used both docker containers and vagrantfiles for development, though not too extensively. In my experience they're both pretty involved for something that requires multiple services running. I think vagrantfile might be a little more accessible for developers. Using docker will eventually require additional understanding of docker/docker-compose and how containers interact whereas virtual machines I think are easier to reason about. For example I think it will be very common for a developer to want to get to a command-line on the system running their phorge services. Doing so with docker requires knowing which container you want (docker container ls) and running an interactive bash (docker exec --it {id} bash). With vagrant it automatically sets up ssh (and handling keys, somehow) so you can do something like vagrant ssh and it drops you into bash on a single machine that has all services running.
I've been working on a diff for this. Diviner is rough as it doesn't parse book titles or descriptions using Remarkup, so I'll also have to make a change to the Diviner engine as well...
Ah, yea... I actually have a change in our company's Phabricator instance that customizes the rendering of titles on diffs and audits, though it doesn't use remarkup rendering on them but just optionally creates links to our external task system. I'm not sure what would be a good solution here, as using remarkup doesn't necessarily seem like the right approach.
I've copied the contents into L1 Phorge Vision Statement which allows us to track signatures
That sounds good to me. I'm hoping to get back to a new approach for T15006 later this week, in cooperation with upstream
Jul 1 2021
I'd like to volunteer to help maintain the releases if that's OK. It's something I absolutely love (tracking changes and maintaining documentation) and I think it'll be a great way for me to support this project.
That sounds great to me! I'm a fan of having someone be the primary release engineer/manager and your volunteering would be very valuable for the project.
In case you're not cc'd on the task, refer to T15006#765
Note that I've been discussing with epriestley in the upstream regarding rebranding. His suggestion regarding diviner is to introduce a ReMarkup rule that allows for using e.g. ${{{ project.name }}} which is then swapped out during rendering, allowing the diviner documentation to reference a non-descript project name that is filled-in when generated/rendered. I think that's something we should consider, and I think will be something that gets submitted/accepted in the upstream.
Note that epriestley has provided valuable insight and even looked at making some updates
https://secure.phabricator.com/T13658
https://secure.phabricator.com/D21678
Jun 30 2021
Thanks for the suggestions - I've updated the document to address them.
I've made some updates to the vision statement document to try and bring it closer to completion. I've incorporated the rest of the outstanding notes and addressed the current comments.
Jun 29 2021
I've created a task upstream to start the discussion about how to rebrand
https://secure.phabricator.com/T13658
Jun 27 2021
This is an area I'm interested in with regards to Harbormaster's future, though I don't have any clear designs on anything. The concept of a merge queue is interesting and something we've started looking into at my company. Here are some resources we've looked at:
- Successfully Merging the Work of 1000+ Developers, article from Shopify
- Keeping Master Green at Scale (PDF), a paper from Uber. Related HackerNews Discussion.
- Merge Train, GitLab's tracking issue for this feature
- BORS, a GitHub merge bot
- Zuul, a "Project Gating" system to drive CI. Relevant pages on Project Gating and Zuul Concepts
Jun 26 2021
There are still a hundred or so more locations that need updated
Attacking a few more instances while searching '.*\s+Phabricator\s+.*'
As a note there are some translated text areas around these changes which I've updated in D25002: T15006: Replacing external-facing trademarks/assets
As a note, when I'm searching for instances of "Phabricator" to swap out I review the entire file and not just the search result instances so all current changed files should be fully updated.
Did a search for pht\('.*Phabricator.*' to find places where "Phabricator" appears on the same line as pht(.
Updated T15006 with additional notes about other things that will need updated.
Searched for pht('Phabricator to find a few more instances to update.
Added a few notes to T15006 about non-translations which we will need to update.
For this diff I'm going to continue the current approach of swapping Phabricator with %s and adding an argument, with the understanding that this might not be the final approach we take.
Jun 25 2021
I took a bit of a further look and this does look like a solid refactor. I think in general we should also aim to add more documentation as we go along which will help to improve others' understanding of how things function. Since there's a lot of existing code that's undocumented I think adding class-level and method-level comments to any which are added or significantly refactored would be good to add for this.
In D25012#422, @Ekubischta wrote:We could move this from the global exclude to just the specific linters (like the txt linter, etc.) - That would be a reasonable request
Thank you for checking out an example CircleCI, both with and without these changes! That gives a lot of confidence that these changes are pretty stable. I just did a quick look through the code changes but would like to sit down later and go through more in-depth if only to learn more about Harbormaster.
I think it makes sense to find some balance based off the impact of a change. If someone is submitting some code documentation changes or typos then I would personally be fine with not requiring a task as long as the diff itself can encompass the details and lints/unit-tests to account for syntax errors. What I'm worried about are larger changes which don't have tasks, as that means someone is putting time into larger changes without seeking input/discussion from others about how to approach the problem. Additionally it may also be possible that someone else is working on a similar change resulting in either duplicated or conflicting efforts.
Jun 24 2021
@avivey has anyone been in contact with Evan that can reach out? I don’t really know of a way to reach him for this type of topic/project.
I would say let’s go ahead and make those changes. I’ll be on later tonight from a workstation and can make those changes then (~8hrs) if needed.
Okay I was able to run lints properly but running unit tests still failed because I'm not running a proper dev environment yet. I'll definitely get this done before considering this change for landing/submission though.
Still need to nuke the 500 Phabricators
- Move the project and org definitions to PhabricatorPlatformSite methods
- Update existing references to moved place
- Fix the default wordmark so it's not immediately translated via pht()
Just to add clarification around T15009: Evaluate legal organization format ("Foundation"), we can opt to create our own organization instead of joining an existing foundation however that involves a lot more paperwork, submissions, legal stuff, etc. The foundations are a means for speeding along that process, where Apache Foundation, Linux Foundation, etc. create their own non-profit organizational legal entity then "adopt" sub-projects which automatically inherit and become part of their entity as long as we abide by their agreements, largely focused around providing open source projects run by open source communities. In turn they provide benefits like being the actual legal entity that owns the trademarks/copyrights/assets for the project, some even offer to be owner of domain names etc. along with providing some legal assistance for e.g. open source license law or even for initially acquiring trademarks/copyrights.
@jupe yea I figure similar to the Phabricator landing page on https://phacility.com/phabricator/ I think we want a basic static page which showcases the project & features, along with some form of T15010, then points to the other content on this install.
This is my understanding of the items in the description currently, please indicate if this is not correct
I'm redirecting the discussion from D25011 to this task
Jun 23 2021
This is roughly what I was planning on
- Move PhabricatorApplication::PROJECT_APPLICATION_NAME into PhabricatorSite::getName() (I have a local change for this)
- Update all existing PhabricatorApplication::PROJECT_APPLICATION_NAME uses to PhabricatorSite::getName() (I haven't yet done this, still figuring out best tooling/environment for PHP development)
- Update PhabricatorCustomLogoConfigType::getDefaultWordmark() to not use pht() but instead have the callers wrap the result in pht().
- Grep for Phabricator and Phacility appearing anywhere within single or double quotes. Likely need to exclude celerity-generated files. Replace with PhabricatorSite::getName()
- Create PhabricatorSite::getProjectOrg() to return Phacility if it's needed from #4
I did skip lint and unit tests for now as I could not get them working properly on my system (something blew up trying to connect to MySQL). I will be setting up a proper development environment at some point.
In D25011#370, @avivey wrote:@deadalnix: want to move the bigger discussion to a ny task? I'm on a mobile right now.
I am in agreement with @Ekubischta’s comments regarding these functional changes staying on hold until we get the branding and quality procedures in place
I think we should check with the community to find someone using CircleCI who is able to check that this doesn’t break backwards compatibility.
Jun 22 2021
This change looks solid but I am a little concerned about pushing up feature/functional changes prior to getting all the branding work done for T15006: Re-brand Phorge. I haven't been able to spend as much time on that recently as I'd like and would appreciate any assistance on it. I'll update the task to clarify the strategy/approaches that I think we need to address.
This ties into T15009: Evaluate legal organization format ("Foundation") - the majority of foundations for open source will support retaining assets like trademarks/copyrights. It would also be useful if they assist in acquiring them in the first place.