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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 8 2021
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.
For the development environment this would probably be best in a diviner book/document instead of a wiki.
Jun 20 2021
One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change. I’m not suggesting we never consider it but it would be better if we can provide tooling/scripts where possible or even create a wider time span for migration. Would MySQL/MariaDB support aliases of some sort? Or maybe there’s a way we can support both namespaces for a time
Jun 19 2021
I created Release Process in our internals wiki to start the documentation on what the release process would look like, based on some of those commented. As we flesh out the plan I’d like to update that.
Abandoning for D25006
Wouldn’t the owners package only cause revisions to be marked, but wouldn’t that leave non-revision commits t not be handled? The herald rules act upon incoming commits rather than ensuring every revision is reviewed.
I updated the herald rules to use O1 so it should work fine next time
Hmm try with this? There are some nuances I think to work out with the herald rule
In D25002#160, @deadalnix wrote:As an asside, you might want to split up the logo rename part of that diff in another diff, this should be able to get in eight away, and there is no reason to wait on a resolution for the translation business to move on with it.
Still need to search for instances of Phabricator appearing anywhere within quotes. Testing all this will be fun.
- Revert the logo and favicon (but keep logo rename)
- Added PhabricatorApplication::PROJECT_APPLICATION_NAME to default to Phabricator
- Updated instances of 'Phabricator' to use the new constant instead