From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 186F13B25E for ; Mon, 13 Jun 2016 10:05:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk 5752140472 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1465826725; bh=TPyXlqeDE7ueb4TPy+WjYCcPG/gE53C2u9CioFHgWSA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OXUgCU4C0t4BClo6u2YXSevO2n0v94CJqDT0DHRa5DXRZScgVFuMjPRE+Hzlcdobc oyh20UksFToIXvwt6b3unPJHkp3jttIih3FE505TQHK4dxndfYF9mwkS1YJabFuRrk RgxABO2If2R3m7JMWEARjVocm0yKUmwDUdgxTjrc= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 89FC7C4010D; Mon, 13 Jun 2016 16:05:24 +0200 (CEST) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Rich Brown Cc: Dave Taht , bloat References: <86DAC1A9-D218-40A4-AD48-D9C0B4B01103@gmail.com> <87twh0j5dg.fsf@toke.dk> <87inxfk28r.fsf@toke.dk> <87wplvij9r.fsf@toke.dk> <2BB7767C-F58D-4A91-9EDF-03C9DD31D882@gmail.com> <87k2hui8uj.fsf@toke.dk> <49626645-6EF1-46B2-80CC-AA8F5A10FF15@gmail.com> Date: Mon, 13 Jun 2016 16:05:24 +0200 In-Reply-To: <49626645-6EF1-46B2-80CC-AA8F5A10FF15@gmail.com> (Rich Brown's message of "Mon, 13 Jun 2016 09:25:08 -0400") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wplt9obf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] Bufferbloat.net - Organizing, curating, and workflow X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 14:05:29 -0000 Rich Brown writes: > Good comments all... Let me preface these responses by saying that I'm > willing to help out, but don't want to get in the way of the rapid > progress being made. > > Toke: Let us know when you think you're done with major > reorganizations... Awesome. I think I'm done with most of the reorganisation stuff now, and am happy to let other people go nuts :) > I also want to see if there's consensus about when and how to make > updates, so that we're not stepping on toes. TL;DR questions: > > - Do we only want to use pull requests, or should core authors have > edit access to github? Quite happy to give out push access. Only caveat is that there needs to be an understanding that updates should be tested and if someone breaks something it is going to break on the live site. However, I figure the people involved here knows how to deal with that ;) > - Or do we use the 'draft' facility? (How?) My thought was that for most things (like news articles, etc), just writing it up and pushing it 'live' is the right thing to do. But there may be cases where several people want to explicitly collaborate on, say, a news article before it is published, in which case the draft facility can be a way to use the git repo to do this. Using branches would be another. >>> - Is there a way to display newest entries? I'd like to see a >>> sidebar element showing the 5 newest posts >> >> Yes, certainly. Was thinking of putting a list of newest news items on >> the front page. However, for the wiki pages it is not necessarily >> obvious that having a notion of 'newest' is useful. > > I see the (new) News column on the home page. The content is right, > but it takes too much space on the page. Maybe there could be a box > above the "Find us elsewhere" panel that just had news article > titles... Hmm, I do tend to use fairly wide monitors. Can certainly move it if it takes up too much space. Feel free to play around with it :) > Random updates to the wiki pages wouldn't need to be mentioned. But if > there's a new topic added, maybe we should publish a corresponding > News item to call it out. I think it's possible to do a 'new items' feed that uses only initial publication date as the sort key; which would make new wiki pages show up as well, but not edits of old ones. >>> - Can an RSS feed be generated automatically? >> >> Yes, but see above. > > I wonder whether an RSS icon could go in the heading of the News > panel... Sure. Just link it to /projects/index.xml - there's already a in the header. >> Yes, this is probably needed. And also fixing broken links (see the >> issue I opened for this on github). > > I figure that members of this group can take on sections as the spirit > moves them. That was my hope ;) > I suspect bigger experiments should be done as PR's (especially if we > figure out how to use github.io pages to display the new form of the > site from our own repos...) Yeah. For local experiments, running 'hugo serve' is all you need. For things that need review, just publishing the files somewhere is all that is needed. If we end up needing to have a long string of review on some new feature (say), it is also possible to host automatic builds from other branches at some other location. >>> - Auto-publish - if it's not already happening, could we >>> re-render and publish after a commit? >> >> Yes, that is certainly possible. For now I figure I'll do it manually >> (it's just re-running a script), but if we get enough activity that that >> becomes a bottleneck, I can certainly set up something automated. > > Cool! It looks as if you added code to do that. Is it operational? Yup. Had some more time last night and set it up. It will automatically pull and build from the master branch whenever it changes. Takes less than a minute from push to live update :) >> It includes a javascript from archive.org which *should* show a link if >> (and only if) an archived version exists. Haven't verified that it >> actually works. > > Ahah! I think this is going to be hard to test - Toke has done too > good a job of matching Hugo URLs to the old Redmine URLs... :-) > > I did fire up LinkChecker on the site, and it found a few bad URLs. > I'll send a separate message about it. Saw that in the logs. I am including a filtered error log below, listing the wiki URLs that seem to be missing. >> Possible. Split out the logs to a separate file; can provide it if >> someone wants to go digging. Or I can just parse out a list of 404 >> errors from time to time. > > I know how to add Google Search, and can take it on after other stuff > has settled. Awesome. > Given the good match between new and old URLs, we might only need a > one-time survey of error.log files to see if there's major traffic to > a particular "lost" page. See list below. -Toke $ grep 404 /var/log/nginx/bufferbloat.access.log | awk '{print $7}' | sort | uniq | grep wiki | egrep -v 'annotate|history|diff|edit|png|version=|jpe?g' /login?back_url=http://www.bufferbloat.net/projects/wisp6/wiki/Wiki /projects/bismark/wiki /projects/bismark/wiki/Capetown /projects/bismark/wiki/Mac_Instructions /projects/bismark/wiki/Wiki /projects/bismark/wiki/Wndr3700v2 /projects/bloat/wiki/ARP /projects/bloat/wiki/bql_enabled_drivers /projects/bloat/wiki/Bufferbloat_and_Freeswitch_Conference_Call_March_9/needthelink /projects/bloat/wiki/Daddy_why_is_my_Internet_Slow_Today /projects/bloat/wiki/Dark_Buffers /projects/bloat/wiki/Dogfood_principle /projects/bloat/wiki/experiment-fun_with_your_switch /projects/bloat/wiki/index /projects/bloat/wiki/introduction /projects/bloat/wiki/mitigations_and_solutions_for_broadband /projects/bloat/wiki/Mitigations_and_solutions_for_Home_Gateways /projects/bloat/wiki/Papers/href= /projects/bloat/wiki/technicalintro /projects/bloat/wiki/todo /projects/bloat/wiki/VoIP /projects/bloat/wiki/VOIP/m2e-delay.PNG /projects/bloat/wiki/What_(bad)_stuff_happens_on_a_congested_network /projects/bloat/wiki/Wiki /projects/cerowrt/wiki/BloatLab_1/ /projects/cerowrt/wiki/BloatLab_1/attached_t.svg /projects/cerowrt/wiki/cerowrt_flashing_instructions /projects/cerowrt/wiki/CeroWrt_flashing_instructions /projects/cerowrt/wiki/evaluating_qos_behavior /projects/cerowrt/wiki/Experiment_-_QoS /projects/cerowrt/wiki/fq_codel_on_wireless /projects/cerowrt/wiki/Installation_guide /projects/cerowrt/wiki/ipv6_tunnel /projects/cerowrt/wiki/Newer_versions_of_fq_codel /projects/cerowrt/wiki/Paris /projects/cerowrt/wiki/Pre-33_Releases /projects/cerowrt/wiki/Setting_Up_SQM_for_CeroWrt_310 /projects/cerowrt/wiki/uftp /projects/cerowrt/wiki/Wiki /projects/cerowrt/wiki/wondershaper_must_die /projects/codel/wiki/best_practices_for_benchmarking_codel_and_fq_codel /projects/codel/wiki/Best_Practices_for_Benchmarking_CoDel_and_FQ_CoDel /projects/codel/wiki/howto /projects/codel/wiki/index /projects/codel/wiki/rrul_test_suite /projects/codel/wiki/Wiki /projects/codel/wiki/Wiki/ /projects/iscwrt/wiki/ /projects/iscwrt/wiki/Wiki /projects/make-wifi-fast/wiki/Wiki /projects/projects/bloat/wiki/BQL_enabled_drivers/ /projects/projects/cerowrt/wiki/CeroWrtScripts/ /projects/projects/cerowrt/wiki/Debugging_CeroWrt/ /projects/projects/cerowrt/wiki/Enable_ECN/ /projects/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat/ /projects/projects/cerowrt/wiki/SQM/ /projects/projects/cerowrt/wiki/Wondershaper_Must_Die/ /projects/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/ /projects/projects/codel/wiki/Bobbie/ /projects/projects/codel/wiki/Cake/ /projects/uberwrt/wiki /projects/uberwrt/wiki/Experimental_patches /projects/uberwrt/wiki/Hardware_evaluation