@Leonore Allez voir notre chouette vieux aeroport! https://en.m.wikipedia.org/wiki/Berlin_Tempelhof_Airport
#fairphone still has unfixed bugs dating from December 2017... by now I wonder if it's worth asking them to spell out exactly which problems are left unfixed by the vendor? This isn't funny anymore 😕
"Please note: Due to missing platform vendor specific patches, the Android security patch level will remain December 1, 2017. Protecting our users is our top priority..."
@hirojin Oh, and I think we're somewhat special among Apache projects because anyone with an apache.org account has write access enabled on the /subversion directory in the ASF SVN repository (access rules on paths in this repository are managed separately per project).
So when someone mails a patch from an @apache.org address we review it and ask "please commit"
Not sure how many other >100 projects at the ASF do that. The culture isn't as fearless everywhere in ASF, I think.
@hirojin Any such offers are made in private when they are made. So I cannot tell you yes or no.
The project is fairly open to new committers generally. Granting write access to all parts of the code needs consensus among existing committers.
But there's a rule that allows any committer to offer anyone (yes, anyone) "partial commit", e.g. to a subset of the code, or to a branch, for any reason at any time.
This rule is important because SVN is not a distributed VCS.
So uh… if anyone knows of any UX Design job openings, I really need work right now.
One of the craziest bug fixes from a first-time #SVN contributer I've ever seen: Commits break with a checksum error if a delta computed on the server happens to be a multiple of 16kb in size: https://issues.apache.org/jira/browse/SVN-4722
This was tracked down patiently by Melissa who showed up on the mailing lists 2 weeks ago when she ran into the problem: https://svn.haxx.se/users/archive-2018-02/0098.shtml
She tracked it down to a variable, left initialized to zero, which should be set to the size of the fulltext: https://svn.haxx.se/dev/archive-2018-03/0066.shtml
Seeing some bad takes about the memcached mess, such as this one: https://isc.sans.edu/forums/diary/How+did+this+Memcache+thing+happen
No ordinary end user is looking at pages on memcached's github or googling stackoverflow answers about it.
They do pkg-thing-install memcached && systemd-turn-on memcached, and then they uncomment one line in their mediawiki config and tada, it just works.
At no point are they going to be warned that they've unleashed an eldritch ddos horror onto the internet.
Software needs good defaults.
I just committed this to #OpenBSD -current:
Back in the history of time, IPv4 had classes of addresses. This was widely acknowledged as a failure. At the same time IPv4 classes were declared a
failure, #IPv6 decided to add
them back because using a mac address for IP address configuration was easy.
Now that we have RFC7217 support we can remove this artificial limitation: allow non-/64 prefixes to be configured by SLAAC.
@phessler @js My recommendation would be making several small fixes to existing filesystems (ffs, fuse, msdos, ntfs, nfs) as a starting point. Get to know the process and the people involved. Working your way up from there to hammer will still be challenging enough. You'd basically need in-depth insight at a level similar to Matthew Dillon's and there are few such people around among all *BSD projects.
You could also ask mpi@. He might be interested but often lacks time.