In D25905#24572, @aklapper wrote:

@Cigaryno: Oops, I am sorry! I had forgotten that this proposal also existed as it wasn't linked under "Revisions and Commits" in T16007. My fault. :-/

@Cigaryno: Oops, I am sorry! I had forgotten that this proposal also existed as it wasn't linked under "Revisions and Commits" in T16007. My fault. :-/

Obsoleted by D25909: Diviner: Contributing Code: Update section on Prototype Changes. I think @aklapper should have instead commandeered this rev but it's still okay to have a new revision instead.

I've created T16007: Discuss the policy for contributing to prototype applications.

In the meanwhile I paste here a proposed alternative that may better reflect the current situation (no need to update the patch - since I guess this phrase will attract more changes):

I agree on discussing the removal of this phrase. I will wait the task, but my opinion is that it's a legacy phrase from a company that had better to do than fixing weird workflows based on Prototypes (and it had sense). But now it's a community and we already work on best effort on everything, including prototypes. Moreover that phrase does not reflect the current situation, since we triaged and fixed 6 bugs on the Calendar prototype Calendar (even if it should be un-prototyped one day) - and probably more evident already-reviewed patches.

@Cigaryno please create a task under Discussion Needed for this - I'm not sure we want to make this policy change.

Fix the typo in line 167

A comment in two parts:
First and most relevant to this task: It certainly would be nice to get some of this into documentation! It took me quite awhile to figure this out when doing my own extension development.

Probably not enough consensus for a mass edit. Best we can do is case-by-case fixes reading warn reports.

(re-opening, there's more work left here)

On it, thank you!

My friend, I think you are affected by this change, and this applies to whatever PHP version

I'm on the latest pull, commit f81e821abf2b275d1778d02a018a4d0af7208be8.
A bit off topic here :) but I'll quickly sum up the issue I'm having (and am in the middle of trying things to fix):

• Visiting https://[phorge instance]/auth/config/view/2/, where my Github auth item is, makes nginx dump a blank 502 page, no further info.
• First instinct is to check the /var/log/nginx/error.log, where I get a PHP stack trace concatenated into one line, and an nginx header length error (reformatted for readability. the PHP error is truncated):

Oh, totally possible that I forgot to update it :)

I'll take your word on it that it's supported, though the current installation guide says otherwise.
Further, I had a few roadbumps on a fresh install to a new server with PHP 8, that I suspect may relate to strlen(NULL) behavior, but I did need to set up PHP 7 to make sure that was or wasn't the case.
(I'm in the process of reproducing those and working out a possible cause or trace. Some manifested as warning banners, one as a 502 on my end in the GitHub auth provider.)

We already support PHP 8...

Partially related, a systemd unit for the SSH server. Proposal in D25497

While it could be nice to have this, in the meanwhile I think that having something minimal like D25434 would be nice

I'm Valerio, a simple person: I see "GNU/Linux" and I say "yeah, land".

This is a nice contribution and definitely would be a valuable addition to the docs, IMO.

I honestly have nothing more to be done here. I would like to set as resolved but there are sub-tasks opened

Note that I like to do NOT mention the stuff phutil_nonempty_stringlike() since it causes extra headaches with incoming objects to many friends. Same for its friend phutil_nonempty_scalar() since it's broken with known scalars (T15239).

avoid unuseful tables

mention the cast thing

mention the cast thing

Basically phutil_nonempty_scalar() cannot be used since, instead of returning false when receiving false, it explodes.

If you need a preview: