Tim spends countless amount of time going through the scripts, read throughs, first recordings, and so on, with Patreons. I've been on many of these read throughs, usually with several engineers in the aerospace industry present, and it's meticulous how Tim makes sure any possible mistake is identified and rectified. Even then, once you upload, there's no editing of a video.
The goal is to bring the subject down to a level where everyday people can still follow. It's not meant to be a college course, so of course there will be some dumbing down.
That's just wrong and I think you've been sucked into the "distortion field" that surround him. I jumped to a random spot in this video and found several inaccuracies in seconds in how he described how the cooling process worked.
This assumes that the person fixing the bug is either the same one who filed the bug, or they were motivated to fix the bug after finding the GitHub issue.
In many cases, the fix comes from within Facebook or from a different contributor when we/they run into the issue themselves.
And this is exactly why React Native is such an unprofessional pile of crap. Random code changes from random people with no prioritization, documentation or coherent history.
If I recall correctly, many of these warnings come from the default settings provided by the starter Xcode template. As we mostly integrate React Native into existing projects here at Facebook, this is something that we're mostly blind to.
As it happens, someone sent a PR the other day that fixed a bunch of these warnings just in time for the new release candidate we just cut this week. Please give 0.56.0-rc a try. If there's any warnings that still need to be addressed, send a PR or open and issue and ping me. This is something we want to actively clean up :)
There's a long tail of PRs to go through and review, and the ones we review may take a while to get to a point where they are accepted, but saying PRs are never accepted isn't quite accurate: https://github.com/facebook/react-native/pulls?utf8=%E2%9C%9...
I'm one of the open source React Native maintainers here at Facebook, and I'm the one who has set the direction for how issues are treated on our React Native repository.
To anyone whose issue I've closed prematurely, it's OK to feel upset about it. Please do let me know when that happens, as that is the signal I'm looking for. Out of thousands of issues that the bot has closed automatically, only a few dozen end up getting commented on after the fact. Some of these issues we won't reopen because there is no minimal repro (usually because they were opened before we started enforcing the issue template, in which case, please open a new issue!), but in many cases all it needs is for a maintainer to go in and re-open the issue.
If you're reading this and you are one of the people actively participating in the repo, and you'd like to get added to the team that manages issues, please reach out. We have a handful of non-Facebook maintainers with this type of access and we're always looking for more. Shoot an email to my first name @ fb.com.
At this time, we're only automatically closing issues that don't make use of the template. The requirements are actually quite lax: all we ask is for you to run `react-native info` so we can get more information about your setup, and a minimal reproducible example. Questions and requests for help do get sent to Stack Overflow, and this is with the community's best interest in mind as we want to focus on bugs and regressions that affect people's apps. For anything that is not a bug report or a request for help, we have an open-ended discussion template that can be used to file issues that used to get closed automatically in the past.
We used to close stale issues more aggressively in the past, which was needed to get us down from thousands of open issues down to a more manageable state. The bot now only closes issues after four months of inactivity. The bot does give a 30 day warning which should be enough for people to verify if the bug is still present in the latest release, in which case they can leave a comment and the bot won't bug you for another 90 days. This way, we can prune out any issues that got fixed in a release - as others have commented, sometimes the people fixing a bug are not aware that an issue was filed for the bug for various reasons.
But the true purpose of the stale bot is transparency: if there has been no activity in the issue in such a long time, it's not something people should expect to see fixed soon. Typically, issues where someone is able and willing to provide a fix for, or long-running issues describing a problem that does not have an easy fix but the core team wishes to fix at some point, will have some sort of ongoing discussion, in which case we protect the issue from being closed by adding the appropriate label ("Core Team" or "For Discussion").
Finally, I want to point out that the project is open source. If you are waiting for a fix to be merged and need to unblock yourself right now, you can always cut a release off your own fork. Please let us know when you do this, as this helps provide us with some signal about PRs that could be prioritized.
Well, I see there's at least been some action on the TextInput regressions that were keeping us on fork! <3
Not that running a patched version is necessarily a huge deal, but it's nice to have that 'this random code is approved by someone that actively works on the codebase' stamp.
(well, still might be on 0.55.3 for the version if NetInfo we can work around, but I do appreciate the project, warts and all)
The hosted parse.com service is meant to support hundreds of thousands of apps. It was not really meant to be self-hosted by individual developers serving a couple of applications.
The data export feature was replaced by the database migration tool we launched on January 28 last year. We highly recommend using the database migration tool as this will ensure that all of your data is copied over and synced to your new database prior to switching traffic over. Tons of apps have migrated in the past year using the db migration tool.
It's terrible that you aren't allowing data to be exported anymore. You shouldn't need to setup a server and go through the migration process just to get your data out.
The prior export feature that allowed data to be exported in JSON format was great, but that was left broken without any explantation.
The "real" Parse service is built to power hundreds of thousands of apps. The OSS Parse Server you run yourself would only need to power a single app. Two very different use cases.
Yes, but it seems that everyone thinks that this is the "Parse Server" being released. It's not, it's just an open source compatible API.
It's important because a lot of the powerful features of Parse aren't included in the new open source server (analytics, config, push). Saying that Parse is open-source seems to imply that these powerful features are available.
The goal is to bring the subject down to a level where everyday people can still follow. It's not meant to be a college course, so of course there will be some dumbing down.