In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.

For example:

  - p4 tracks file metadata of client workspaces on the server (sync'ed locally, opened for edit, file revision, etc) and uses this as the basis to avoid doing unneeded work.  If this becomes desync'ed, a reconcile or force sync must be used.  A reconcile can take hours, potentially days; it tries do detect file moves by default, so likely at least O(c^n) for some c>1. I have never personally seen a default reconcile operation _complete_ over any modestly large game code base, and in practice, people accumulate a litany of workarounds and scripts to fix this for themselves.

  - Scripting p4 is a nightmare. Documentation is poor, schemas do not exist, and all the language-specific libraries are just thin wrappers over its C++ API.

  - By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings. This works until you have a mixed-OS environment, and discover a part of the pipechain that _must_ have a certain style.  There are various levers to pull to make this better, but I've yet to find something fool proof.

  - By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited.  This means, to avoid having to do this manually, every tool you use needs to be p4-aware.  Or, you can turn this off, and choose to contend reconcile instead. (See above)

  - Branching a modest game project, with, say, Unreal source code, can take hours.  And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.

  - p4 is licensed by the user-account. Every user entity in p4 not intended exclusively for performing backups and maintenance operations counts toward this, including users required to integrate with other services.  Plus, often times, these integration users must have admin access to be useful. The security posture is horrific.

This is, for better or worse, what is being done to incorporate aboriginal names into things like streets and bridges in places like Vancouver.

- [stal̕əw̓asəm Bridge](https://en.wikipedia.org/wiki/Stal%CC%95%C9%99w%CC%93as%C9%9...) - [šxʷməθkʷəy̓əmasəm Street](https://vancouver.ca/news-calendar/musqueamview-street-signs...)

I see the practicalities of adopting this IPA-lite form, but it's a struggle to use, even though I've previously been trained in IPA.

How does scattering work? Why does light scatter? _What does scattering even mean in the context of light?_

Between CD/DVD drives, writers, Zip Drives, and extra hard drives, it wasn't unusual for a workstation to naturally end up with G: or H:, before mapped network storage became common.

We thought this, too, when choosing Salt over Ansible, but that was a complete disaster.

Ansible is definitely designed to operate at a lower abstraction level, but modules that behave like desired state declarations actually work very well. And creating your own modules turned out to be at least an order of magnitude easier than in Salt.

We do use Ansible to manage containers via podman-systemd, but slightly hampered by Ubuntu not shipping with podman 5. It's... fine?

Our mixed Windows, Linux VM and Linux bare metal deployment scenario is likely fairly niche, but Ansible is really the only tenable solution.

The challenge, ironically, was convincing management that adding IPv6 was the thing worth trying. After almost a week of getting nowhere (and almost 2 weeks of outage), I forced the issue by saying "Look, I'm doing this. I need one engineer for 2 days. If it doesn't work, then it doesn't work."

He got the change implemented in 2 hours. QA OKed it the next day. The topic never came up again.

At the end of the (very long) process, I just hard-coded the reference request XML given by the particularly problematic endpoints, put some regex replacements behind it, and called it a day.

We both self-host and pay for the service. There is ample engagement from the development team with the larger community. There are also a myriad of open source projects without the same licence restrictions that Sentry-the-company publishes or maintains which make up key functionalities in Sentry-the-product.

It took the group several years to narrow in on.

https://packaging.python.org/en/latest/specifications/inline...

Especially useful if the script has dependencies on packages in private repos.

In general, Canadian labour laws prohibit what are typically considered unpaid internships, although it varies slightly by province.[1][2] My understanding is that this is not the case across most of the United States.

[1]: http://www.labour.gov.on.ca/english/es/pubs/internships.php [2]: https://www.labour.gov.bc.ca/esb/igm/esa-part-1/igm-esa-s1-w...

The study of Linguistics, explicitly, does not deal with orthography, or the written system of languages. There are of course exceptions with good reasons, but orthography systems are rarely, if ever, good representations of the systems of auditory communication that are formally considered languages. An orthography system can be heavily influenced by geopolitics (Chinese), have severe ambiguities (Arabic, the various Latin alphabet systems), or have been created retroactively (many languages of indigenous peoples). While it is convenient to map a spoken language to its related orthography when discussing topics such as syllables, inflection, and morphology, it is rarely appropriate when studying linguistics formally.

As for Japanese, while it is true that its alphabet system has a relatively straightforward mapping to its phonology, the mapping itself is, unfortunately, not unambiguous. Japanese has a tonal system[1] that is not explicit in its orthography. There are examples of phonemically distinct words that are identical when written in hiragana/katakana.

Finally, there exists a moraic system[2] which sits between the phonemic and syllabic abstractions. Japanese, especially, have many phenomenons that cannot be adequately modelled unless working in this in-between system.

[1]: http://en.wikipedia.org/wiki/Japanese_pitch_accent

[2]: http://en.wikipedia.org/wiki/Mora_%28linguistics%29

Strange, perhaps, but present. To a native Chinese and Japanese speaker like myself, the list of collective nouns for animals in English is staggering, almost mindblowing, and appears absolutely arbitrary: http://en.wikipedia.org/wiki/List_of_collective_nouns_by_sub...

Whether a change comes in the form of code fixes, documentation improvement, refactoring, design changes, or infrastructural modifications, the burden of understanding the potential scope of damage and doing the actual work is always, always on the contributor. Convincing another to take on the work on their behalf is always a possibility, but it should not be hard to see why design changes proposed through such a channel will often be pushed to the back of the queue, unless for some dire need.

Designer or coder, there is no excuse for not doing due diligence in making sure a contribution is a good contribution.

Looking at the discussion so far, there appears to be at least some consensus that non-trivial effort above and beyond the (hopefully) expected hand-holding must be dedicated to designers in order for them to become good contributors. And, in corollary, the natural conclusion is that it's unrealistic to expect designers to put in the necessary effort to become good contributors on their own.

Following from the above, the more crucial questions, I think, are "How do we convince projects that they should go out of their way to attract designers", and, "Do you really need designers? Really, really, need them?"

Comments URL: https://news.ycombinator.com/item?id=1874959

Points: 1

# Comments: 0