I wanted to set up some docker/compose file or possibly a VM but didn’t get far since neither of those are great solutions on windows, primarily for getting local code into the container/vm. My goal would be to get a quick setup time with a rapid dev/test cycle. For me to make progress I’ll likely have to switch to mac or Linux.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 21 2023
Apr 19 2023
Getting set up with a development environment (including database~) along with configuring the local instance and populating it with sample data is extremely daunting and is frankly why I haven’t done much contributing. I lost my dev environment a few years ago and have tried only once to get set back up, spent a few hours and never came back to it. It doesn’t help that arcanist’s self linter isn’t usable on windows systems.
Apr 9 2023
Okay real accept
Thank you for investigating! I think this is reasonable to land, given the investigation and testing there aren’t any immediate issues that seem to crop up on mobile.
From a usability perspective this feels nice to be immediately at something more useful. I would just try to find why the dashboard page works as expected but the main landing page doesn’t. If this change is still the underlying reason it seems good to me.
Does this change anything other than the landing page? When using mobile the first thing I do is click the link to dashboard and it shows properly there. Any idea why the home page behaves differently from the dashboard page?
Sep 21 2022
Aug 23 2022
Somewhat related - see T15050
Aug 22 2022
Could it be cached?
Aug 21 2022
Could you elaborate on what this would help with? I recall reading something in Phabricator’s past that the current url scheme is intentional as opposed to using the monogram/slug. I did a quick search and couldn’t find much, though in this change release
https://secure.phabricator.com/w/changelog/2015.51/
Removed dedicated titles/slugs. Phame posts now automatically generate readable URIs, but the slugs are no longer semantic.
We should investigate the history related to the current URL scheme before making a change. My suspicion is that it has to do with phase posts being “public” or published where having a url with part of the title is very common for linking across other content.
Aug 20 2022
Jul 26 2022
Jul 12 2022
Sorry about the delay on this. I think the emails didn't go out until later and I've not had much time to dedicate to this project as expected. As of today's meeting the current plan is for @avivey to do the merge with latest updates from upstream and push, sans review.
May 21 2022
@dcog I think the differences with the Harbormaster changes are due to the different approach taken. We planned to do the approach which you took in D25036 which re-played the Phorge diffs on top of phabricator, however in D25040 I just did a merge of the phab/master branch into phorge/master where the Harbormaster changes already existed. Since upstream didn't modify the same Harbormaster files there were no conflicts and things merged appropriately. I did a sanity check of files changed on D25005 with the files changed on D25040.
Do we even have servers to run the tests on?
I did not think we had Harbormaster set up to run unit tests - I think that involves configuring both Harbormaster and Drydock, and possibly Almanac which I don't think anyone has done.
Though it does appear additional work has been landing upstream today
Any concerns about landing those changes? Once I land I'll see about updating this instance which should make accessing the repositories possible again.
May 20 2022
I had to skip unit tests because phabricator/phorge unit tests require a local database to test against which I don't have setup. The lint failures are either pre-existing TODO's being flagged or the newest lint which catches product name literals. We should fix the literals but I don't want to fix that as part of the merge -- would rather do that in a separate change.
Unit tests all pass. For the two lint errors, one is erroneous checking characters used in a non-code file, the other is pre-existing and fine to leave alone.
Merged the arcanist repository in D25039
May 3 2022
It looks like upstream has issued a number of updates which we'll want to pull in. From {E4} we discussed doing the following:
Apr 28 2022
Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675
Evan recently landed a boatload of changes to address this under https://secure.phabricator.com/T13658
Apr 20 2022
There is quite a bit of text that is setup like this:
pht( 'blah blah blah %s blah blah'. 'blah blah Phabricator blah %s'. 'blah blah.', $var1, $var2);
Apr 19 2022
Apr 6 2022
Mar 29 2022
A few thoughts. This sounds like a great idea as searching by article title seems a little fragile as you mention. I think a good practice for using the proposed @link would be to fully namespace it somehow like @link development.processes.i18n, though I'm not totally sure what that looks like as I'm not familiar with the Diviner format or structure. If we have the use of namespaces then managing multiple @link declarations might lead to confusion or tedious to maintain. To me this also feels more similar to something like an @id rather than @link. What are your thoughts?
A highly unfortunate side-effect of T15077: Rebrand: Tracking task is that it will invalidate a ton of translations. My guess is that upstream did not want to maintain these translations as part of the release product, possibly due to not requiring translations be part of the Phabricator release process. If we pull them into the Phorge codebase then we would likely need to update all translations for any text changes made during development, prior to release. I think it would make sense to host the translations in a repository here but I would worry about them quickly falling out of date. Handling of translations is likely a larger-sized project that we would need help managing.
As part of {E1} we reviewed this as a priority item, and have created T15077: Rebrand: Tracking task for concrete first steps forwards. There is a lot of text to update and review and that task is setup with instructions on how we're approaching it as well as listing out all the individual applications to update. Anyone interested in assisting please review that task and feel free to put your name on an application/folder, as well as ask any questions for clarification.
I put up some coding guidelines that I could recall from when I was working with upstream on example changes. I won't be back at my home office for another week so there may be some things I'm missing but I think a number of things were covered/discussed with Evan on the example changes in https://secure.phabricator.com/D21712.
Mar 25 2022
Ah interesting. My own preference would be updating PhabricatoPeopleProfileController as I would associate this more as a view-level change but looking again at how this is structured I don't think it would cause any issues and I don't feel too strongly about changing it.
Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).
I've only looked at the new auth frameworks briefly (WebAuthn, is there another standard too?). My basic understanding is that the browser provides the client with its own certificate which HTTP requests are able to include with it, as a means of providing authentication for the user. This seems like a reasonable thing to allow though I'd also be interested in learning more about the tech in general.
Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?
I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...
Mar 21 2022
For an account marked as spam we might also want to hide their username from the UI, essentially hiding all possibly user-entered text from appearing on any page so it won't show up in search results.
Mar 20 2022
Interestingly accessing /status on secure.phabricator.com seems to return a json object instead of ALIVE.
Mar 16 2022
I also created a Jitsi meeting and put that in the description of {E1}.
I turned on prototypes and created {E1}, adding everyone currently (individually) cc'd on this task as an invitee.
Yeah, I think we'd like to try and update arcanist to account for this with a general solution if possible and not making updates for each individual linter which might necessitate this. There's probably some general restructuring that needs to happen to account for the same odd scenario with Java and so forth.
Mar 15 2022
I think that's roughly what I ended up doing in https://secure.phabricator.com/D14632 for launching separate Java linters, where java had to be configured as the "interpreter" and checkstyle.jar (or whatever) configured as the "binary" (https://secure.phabricator.com/D15067 added the ability to pass flags to the "interpreter").
Phabricator has a Calendar application but is prototype. I believe it's mostly functional -- should we enable prototypes on this install to try and use the calendar application for organizing this event?
Mar 13 2022
Based on the entries so far it seems like possible window of time for meeting would be 4pm-8pm GMT? That would mean 9am-1pm for GMT-6 and 6pm-10pm for GMT+2. If that time window seems reasonable would any day of the week be better than others?
Should this be the responsibility of the linter/tester and not part of Arcanist itself? Updating arcanist to handle the many different environment-dependent systems for languages would mean accounting for nearly every language like Javascript/npm, Ruby/rubyenv, etc. right?
That would be useful, though we might not want all disabled accounts to have their profiles description hidden for accounts disabled which aren't spam.
Mar 11 2022
Mar 7 2022
Thanks for reporting, I've disabled the account.