Re: [b2g] Relevance of Super-Review (Was: Hardening the review requirements for changing .webidl files)
Another rather nice purpose for the s-r flag, in my experience, is exposed during onboarding of fresh, remote, engineers (like I was ~1 year ago): it allowed me to get acquainted with the review cycle while working on Good Next Bugs(tm) that touched intricate parts of the codebase, like DocShell, and the knowledgeable colleagues behind them. Also the social part of that process, I mean. Being remote makes one (me) rely much more on the process facilitated by the tools in use and there are people behind them. And history... lots of that. In other words, this particular part of the process, s-r, made me connect with people that I respect and now know a bit better. Whether the s-r flag is meant for this purpose or not is debatable, but this is just what I experienced in practice. Do with this info as you please ;) Cheers, Mike. On 26 Apr 2014, at 04:34, Boris Zbarsky bzbar...@mit.edu wrote: On 4/25/14, 10:06 PM, Doug Turner wrote: I tend to think that super review is a dumb idea. It's a hack around people doing bad reviews is what it is. There are certainly patches that are landing without official sr but that do the moral equivalent of what sr is supposed to ensure: running the API design by someone other than the reviewer whose judgment the reviewer trusts (via feedback or needinfo or whatnot). As long as all our reviewers are competent enough to know when to do this (aka know what you don't know) we don't need an official sr requirement. In practice we seem to have been dealing without official sr, as you note. Of course if all our reviewers knew what they don't know we also wouldn't need a commit hook on dom/webidl to catch patches there landing without DOM peer review ;) -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/26/2014 09:03 PM, Boris Zbarsky wrote: On 4/26/14, 11:32 AM, Zack Weinberg wrote: it might be better to just create files in the ultimate target directory if we aren't already. We create the file before the user has picked the ultimate target directory. ... maybe we should stop doing that? Not in this bug though ;-) zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTXQ7HAAoJEJH8wytnaapkfZYP/iOHjrT0X2WAFHTBrqW0FaJb eL5rtCZ02CXPGmM5P95ah73miomaPxldFMdgcsvYCr4LHRjvtgdGs6nCsNv8DfUm r/jrG+YVvM9Tc8gjoeZa85EJrcDc9vXsjjfJk3ZLt/kZHHFRrg49omyMsZlHyTlj M5NslCeQ1iZuK7d+Us8Dw8ql+c5uMYr8EwH5HeVV8iJcCzb7wpnDGXE9o/7MBTFi 3xwFV12nN+h0U2axDuJ5NRzfTI7oFOHhyx7KyUPvcNpULYBYGEV7PqTz2JCbO3to Th1MPMsGo1M4reGdf120SNrtgyrBVXvX54JflICAqrPg28K1HunXJvGh7BRudJR3 dWH+GY5UCu7hpavViK+AAEB7W9dhOVYp5akSf0Sub3n+Rq8F0N+u+3BLjikfDhVx 0CcpomyJBsp6D0HgKY7tPiLGgpH5068xVscgzeBwTqkWnDlihfjXxDaNbbtgrSXb 5f8mZiUXzx6JwWnrPYAfpr/cMlUATJfZyMzSj5wyXMrRULaCjtnxOL5oK6Asa19D 21ZCVpqh/kr3gW1ExROHSz61G65mjJ+V0NmD5Y0q5r25rmkiJhmxkGObVbchSdMA NDd5QbGMowAxv6WldLfImvJwrcjOX1n9wq7rz83uP9AjYkLNk2wM/LRb+hH4Unu+ ED3FxN4Fq1icUjpTKO5+ =DuO6 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
On 4/27/14, 10:06 AM, Zack Weinberg wrote: maybe we should stop doing that? The issue is deciding where to put the incoming data. We can't just buffer it in RAM while the download is proceeding and the user has gone to lunch without selecting a download location, because in many cases we'll OOM. I'd love for us to have a better setup than we have now; we just need to figure out how to do it. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
Hi Zack, - Original Message - From: Zack Weinberg za...@panix.com To: dev-platform@lists.mozilla.org Sent: Saturday, April 26, 2014 12:11:23 PM Subject: Re: OS.File design issue from bug 961080 (making downloads respect umask) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/26/2014 12:17 PM, Dave Hylands wrote: The basic user/group/other permissions are always set to the mode argument to open() or mkdir(), and-not the umask. The permissions used by open are affected by umask. If you use open/creat to create a file with 0777 permisions and umask is 022 then you will get a 0755 file. See: http://linux.die.net/man/2/open and search for umask I am aware of this. I see now that the mode argument and-not the umask reads like the umask is irrelevant, but what I actually meant was the permissions are set to mode ~umask. (It now occurs to me that if the download manager moves files to a different directory after it finishes downloading them, we need to reset their ACL and group ownership as well as applying the umask. The umask would have already been applied when the file was created. Well, the entire point of bug 961080 is that files are being created mode (0600 ~umask) rather than (0666 ~umask) as is more typical, and that it's not safe to just switch to open(,, 0666), we have to chmod it later. If you copied the file, then it would get assigned the correct group. Being the owner of a directory but not a member of the group seems unusual. Consider a directory like this (numeric mode 3777): drwxrwsrwt 25 root root 4096 Apr 20 12:54 test.d Anyone can create files in this directory, and the group of files so created is forced to group 'root', *even if* they are not themselves members of that group. Right. The reason you use the group sticky bit is because the directory is used for sharing. If you create the file outside of the directory and then move it in, then the original group of the file is retained. If you create the file outside of the directory and then copy it in, then group as determined by the group sticky bit would be used. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
- Original Message - From: Boris Zbarsky bzbar...@mit.edu To: dev-platform@lists.mozilla.org Sent: Saturday, April 26, 2014 6:03:42 PM Subject: Re: OS.File design issue from bug 961080 (making downloads respect umask) On 4/26/14, 11:32 AM, Zack Weinberg wrote: it might be better to just create files in the ultimate target directory if we aren't already. We create the file before the user has picked the ultimate target directory. Right, so we should use the file that we started downloading to as a cache. You stat downloading the file to the temp location. Once the user selects the final location, you open the file in the final location and start copying the file from the temp location to the final location. Eventually, your copy should catch up with your download, in which case you can stop writing to the temp location and resume writing to the final location. In the worst case this has the disadvantage of requiring twice the amount of disk space as the downloaded file. The other approach, is to do what we're doing now (download to temp, move to final) and then attempt to fixup the group ownership after the move. There are corner cases where this won't work (you can create directories that are writable, but where you can't examine the directory to determine if it has the group sticky bit set or not). You might be able to create a dummy destination file, read the ownership of this dummy destination file, remove it, fixup the ownership of the temp file an then move it to the destination, but that may cause other problems (for example, if the directory had watchers that were performing actions when new files show up). And you could do a hybrid approach where if you can determine what the correct group should be, then you fix it up on the temp file and move it in. And if you can't determine the correct group, then you copy it in. Dave Hylands ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Who is the moderator/owner of this group?
Every time I send an email to dev-platform, I get the following email as a reply. Can we get supp...@lativio.com removed from the mailing list? Dave Hylands - Original Message - From: supp...@lativio.com To: dhyla...@mozilla.com Sent: Sunday, April 27, 2014 9:15:14 AM Subject: Thank you for your email Thank you for your email, unfortunately this email address is no longer in use. Please find below new contact details which you may use instead: SizeGenetics E-mail: supp...@sizegenetics.com Phone: +44 115 979 8446 PenisHealth E-mail: supp...@penishealth.com Phone: +44 115 979 8447 LoveCentria E-mail: supp...@lovecentria.com Phone: +44 115 979 8448 Proactol E-mail: supp...@proactol.com Phone: +44 115 979 8449 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Who is the moderator/owner of this group?
On Sunday 2014-04-27 09:29 -0700, Dave Hylands wrote: Every time I send an email to dev-platform, I get the following email as a reply. Can we get supp...@lativio.com removed from the mailing list? To answer your question in the subject, the moderator of the (mailman side of) this group is listed on: https://lists.mozilla.org/listinfo/dev-platform which says (at the bottom) that it's bsmedberg. Note that the mailman (lists.mozilla.org) - NNTP (news.mozilla.org) - google groups interaction means that moderators sometimes have limited power, since they're only moderator for what happens in mailman. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Who is the moderator/owner of this group?
Note that I filed 1002263 for this. On 2014-04-27, 7:58 PM, L. David Baron wrote: On Sunday 2014-04-27 09:29 -0700, Dave Hylands wrote: Every time I send an email to dev-platform, I get the following email as a reply. Can we get supp...@lativio.com removed from the mailing list? To answer your question in the subject, the moderator of the (mailman side of) this group is listed on: https://lists.mozilla.org/listinfo/dev-platform which says (at the bottom) that it's bsmedberg. Note that the mailman (lists.mozilla.org) - NNTP (news.mozilla.org) - google groups interaction means that moderators sometimes have limited power, since they're only moderator for what happens in mailman. -David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: NS_IMPL_ISUPPORTS and friends are now variadic
Bugs 900903 and 900908 introduced variadic variants of NS_IMPL_ISUPPORTS, NS_IMPL_QUERY_INTERFACE, NS_IMPL_CYCLE_COLLECTION, etc. and removed the old numbered macros. So, instead of e.g. NS_IMPL_ISUPPORTS2(nsFoo, nsIBar, nsIBaz), simply use NS_IMPL_ISUPPORTS(nsFoo, nsIBar, nsIBaz) instead. Right now, the new macros support up to 50 variadic arguments. Note that due to technical details, the new macros will reject uses with zero variadic arguments. In such cases, you will want to continue to use the zero-numbered macro, e.g. NS_IMPL_ISUPPORTS0(nsFoo). Cheers, Biru ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
On 4/28/14, 12:18 AM, Birunthan Mohanathas wrote: Right now, the new macros support up to 50 variadic arguments. If someone uses more than that, will that fail to compile or silently ignore the extra args? -Boris P.S. I know, the right answer is they need fewer interfaces... ;) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
On 28 April 2014 07:29, Boris Zbarsky bzbar...@mit.edu wrote: On 4/28/14, 12:18 AM, Birunthan Mohanathas wrote: Right now, the new macros support up to 50 variadic arguments. If someone uses more than that, will that fail to compile or silently ignore the extra args? It will fail to compile. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: NS_IMPL_ISUPPORTS and friends are now variadic
On 4/28/14, 12:38 AM, Birunthan Mohanathas wrote: It will fail to compile. Excellent! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
