Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
On 08.07.2012 22:33, Daniel Gruno wrote: [ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs [ ] 0: I don't care [ ] -1: Don't adopt the system, because Thanks for enduring your work on this - glad to see that it has become comments.a.o. in the meantime! I'm in favor of enabling it for 2.2/2.4, generally speaking, but am having some concerns with regard to the proposed approval policy: it changed from the Comments will be moderated by appointed moderators to Comments will, in general, be allowed through without pre-approval. Comments with hyperlinks in them will require approval from a moderator before they are shown on the site [1]. Auto-approval of comments makes me feel somewhat uneasy - on the one hand, there's the risk of inappropriate/incorrect content appearing on httpd.apache.org and going unnoticed for some time, and on the other hand, this means that input validation (Name and Comment fields in particular) has to be very tight... is http://c.apaste.info/source/add_comment.lua the current version of the code which validates the input? (If so, it's e.g. missing checks for https URIs, and at least at first sight, I couldn't spot any further checks on the POST input you're processing [the site, page, thread variables etc.].) Kaspar [1] http://wiki.apache.org/httpd/DocsCommentSystem?action=diffrev1=6rev2=7
Re: [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
On 07/11/2012 08:24 AM, Kaspar Brand wrote: On 08.07.2012 22:33, Daniel Gruno wrote: [ ] +1: Adopt the comments.a.o system in the 2.2 and 2.4 branch of docs [ ] 0: I don't care [ ] -1: Don't adopt the system, because Thanks for enduring your work on this - glad to see that it has become comments.a.o. in the meantime! I'm in favor of enabling it for 2.2/2.4, generally speaking, but am having some concerns with regard to the proposed approval policy: it changed from the Comments will be moderated by appointed moderators to Comments will, in general, be allowed through without pre-approval. Comments with hyperlinks in them will require approval from a moderator before they are shown on the site [1]. Auto-approval of comments makes me feel somewhat uneasy - on the one hand, there's the risk of inappropriate/incorrect content appearing on httpd.apache.org and going unnoticed for some time, and on the other hand, this means that input validation (Name and Comment fields in particular) has to be very tight... is http://c.apaste.info/source/add_comment.lua the current version of the code which validates the input? (If so, it's e.g. missing checks for https URIs, and at least at first sight, I couldn't spot any further checks on the POST input you're processing [the site, page, thread variables etc.].) Kaspar [1] http://wiki.apache.org/httpd/DocsCommentSystem?action=diffrev1=6rev2=7 Hi Kaspar, No, I haven't updated that source repository since we moved it all to the infra SVN repo about a month ago. It is now in place at https://svn.apache.org/repos/infra/infrastructure/trunk/projects/comments/ and has been rewritten extensively. names and comments are checked for http(s) schemes, size (no more than 2500 characters allowed) and so on, and while comments require approval if a hyperlink is found that doesn't point to an official apache web site, names with hyperlinks are flat out denied. I think the general idea has, from the start, been to allow for comments to go through without pre-approval, at least for a period so we can see if that's what we want. If we later on decide that all comments needs approval before they are shown, then fine, we'll do so. The system is geared to respond to a lot of different wishes from different projects, for example, some may choose to enable Gravatar avatars for their comments, while others may not (this is not enabled for the httpd site by the way ;) ). As for comments going unnoticed, we currently have four people who automatically receive an email when someone posts on the site and we have the option to add *every single Apache committer* to this list of people moderating our site, so I think any 'bad' comments will be spotted rather fast and removed. We also have other options up our sleeves: 1) We can require that all posters be registered users first 2) We can ban the sorry people that try to spam out site 3) We can temporarily disable comments on the fly if something goes wrong I hope this answered your concerns, and if you have any other suggestions for how our little part of comments.a.o should work, please do say so, and I'll see if I can figure out a way to make it work. With regards, Daniel.
Re: Time for Apache httpd 2.4.3 ??
On 2012-07-11 05:09, Jim Jagielski wrote: Just how supported and standard is this? Chrome seems to use it for something else: http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal I was told by Google that they are phasing this out (this may already have happened), and then will fix http://code.google.com/p/chromium/issues/detail?id=109012. Not that it *is* implemented in Firefox 14, shipping next week: https://bugzilla.mozilla.org/show_bug.cgi?id=714302. Best regards, Julian
Re: Time for Apache httpd 2.4.3 ??
Roy, as Main Dude for compliance, any issue with getting https://issues.apache.org/bugzilla/show_bug.cgi?id=53292 into trunk (and 2.4.x)? On Jul 11, 2012, at 3:51 AM, Julian Reschke wrote: On 2012-07-11 05:09, Jim Jagielski wrote: Just how supported and standard is this? Chrome seems to use it for something else: http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal I was told by Google that they are phasing this out (this may already have happened), and then will fix http://code.google.com/p/chromium/issues/detail?id=109012. Not that it *is* implemented in Firefox 14, shipping next week: https://bugzilla.mozilla.org/show_bug.cgi?id=714302. Best regards, Julian
Current configuration of httpd site on comments.a.o
As to not clutter the vote with too much stuff, I'm posting a new thread here with some more in-detail information about how the httpd project is set up on comments.apache.org, and what will happen if the vote passes tonight: = Options that are enabled: = - Users have to register an account and validate their email in order to receive reply notifications (thanks for this idea, Stefan) - HTML is NOT allowed - Comments cannot be longer than 2,500 characters. This should be enough to write a couple of paragraphs and show some configuration examples. - Names cannot contain links - Comments that contain links other than those pointing to *.apache.org are flagged as 'not approved' and will need to be approved by a moderator before showing up on the site = Options that are not enabled, but can be: = - Posting a comment can require a registered account - Users can use Gravatar avatars next to their comments - Posting new comments can be disabled - Showing comments can be disabled Non-committer moderators Users that are not committers can be permitted to moderate our site. This can be a great way to allow new people to be semi-committers without having to actually invite, vote and set them up as committers just yet. Currently, we have one user, Sling (Mathijs) set up as a moderator for the httpd site, and I have full confidence that he'll do an excellent job, just as he is doing, helping out on our IRC channel. == Integration of comments.a.o into the docs: == Once the voting is done, and provided the vote passes, I will start integrating the comments system into the 2.2 and 2.4 branch. I won't be doing it tonight, but rather tomorrow when I am satisfied that any remaining kinks in the system has been dealt with. By holding off till tomorrow, we should have a fresh set of eyes on the launch, in case we start receiving many comments. I will start by adding the system to the 2.4 branch, and let it work for a day or two before adding it to the 2.2 branch, as 2.4 presumably has less traffic and thus would be easier to fix should anything be off about the system. If there are any other concerns or just curiosities, by all means, reply to this email and we'll discuss them in this thread. With regards, Daniel.
Re: Time for Apache httpd 2.4.3 ??
On Tue, Jul 10, 2012 at 10:16 AM, Jim Jagielski j...@jagunet.com wrote: I'd like to propose an Apache httpd 2.4.3 release RSN... I'll RM. FYI I'd like for this backport to make the cut if anyone can review / Jim can wait since it's frustrating for users to debug. * core: AllowOverride Options inadvertently treated like AllowOverride Options=FollowSymlinks after r1052419 PR53444 trunk patch: http://svn.apache.org/viewvc?view=revisionrevision=1359976 2.4.x patch: trunk works (+ CHANGES) +1: covener
mpm-event-optimization
About 4 months ago we moved Paul's event optimization stuff to its own branch, and since then no work as been done on it at all... I'd like for us to consider putting it back into trunk, so we can work out the bugs and issues and getting it up to snuff. This is in conjunction with my effort to reboot 'simple' (which I've been working on externally)...
Re: Time for Apache httpd 2.4.3 ??
I don't know of any issues with 308, and Julian generally knows what he is doing with regard to HTTP. In general, we should consider the IANA registry to be authoritative unless it is a known bug, which means we should support everything in http://www.iana.org/assignments/http-status-codes/http-status-codes.xml Roy On Jul 11, 2012, at 5:46 AM, Jim Jagielski wrote: Roy, as Main Dude for compliance, any issue with getting https://issues.apache.org/bugzilla/show_bug.cgi?id=53292 into trunk (and 2.4.x)? On Jul 11, 2012, at 3:51 AM, Julian Reschke wrote: On 2012-07-11 05:09, Jim Jagielski wrote: Just how supported and standard is this? Chrome seems to use it for something else: http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal I was told by Google that they are phasing this out (this may already have happened), and then will fix http://code.google.com/p/chromium/issues/detail?id=109012. Not that it *is* implemented in Firefox 14, shipping next week: https://bugzilla.mozilla.org/show_bug.cgi?id=714302. Best regards, Julian
Re: mpm-event-optimization
On Wed, 11 Jul 2012, Jim Jagielski wrote: About 4 months ago we moved Paul's event optimization stuff to its own branch, and since then no work as been done on it at all... I'd like for us to consider putting it back into trunk, so we can work out the bugs and issues and getting it up to snuff. This is in conjunction with my effort to reboot 'simple' (which I've been working on externally)... But there have been quite a few bugfixes in trunk's mpm event since the branch. We should get these into 2.4 first before we do radical changes in trunk. There are also the patches from http://mail-archives.apache.org/mod_mbox/httpd-dev/201203.mbox/%3C201203022118.08839.sf%40sfritsch.de%3E but I didn't have enough cycles to finish and commit those, yet. Of course, this should not prevent anyone from committing improvements to the mpm-event-optimization branch.
[Result] [VOTE] Adopt the comments.a.o system to the 2.2 and 2.4 branch of the httpd docs
The votes are in: +1: 9 (humbedooh, joes, issac, rpluem, druggeri, rjung, lgentis, sfritsch, rbowen) 0: 0 -1: 1 (mads) As this is a majority vote issue, the vote has passed and the integration of comments.a.o into the 2.2 and 2.4 branches will begin tomorrow (that is, 2.4 will start tomorrow, 2.2 will probably be Friday). We have a new feature on comments.a.o which is support for mailing list notifications, and I think that it might be a good idea for us to consider whether we should either create a separate mailing list for people who wish to follow new comments on the sites, or whether we should simply plug it into one of our existing lists, such as docs@ - ideas are welcome :) As with my previous letters, I encourage those of you who haven't tried out the comment system to take a glance at it, post an example comment in the trunk or check out the moderator panel. With regards, Daniel.
