From owner-freebsd-doc@FreeBSD.ORG Sun Oct 30 13:04:59 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8AF3106566B; Sun, 30 Oct 2011 13:04:58 +0000 (UTC) (envelope-from sonic2000gr@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7B88FC08; Sun, 30 Oct 2011 13:04:58 +0000 (UTC) Received: by faar19 with SMTP id r19so6895947faa.13 for ; Sun, 30 Oct 2011 06:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=iWlWmEiF6Y7jgy7GHdpqGtQOPHMqdEuGsa6hwU/sNBQ=; b=VSE6YVQZatkiO0kHz+WlMbBQgzDhmOHCntOv5Dn1WqRExyOAkKTlpFSRF81UzidEVZ ckz4zZcLakg26gw2+x/S7UhL18jOlaL/6Vu88hIwUQ9TjcWB0ry4gLyd3BdCS9tU4IUC s+e/21/Uo6lNLw62MZbj7tnksB9klrbT190UY= Received: by 10.223.61.211 with SMTP id u19mr21442303fah.29.1319979897326; Sun, 30 Oct 2011 06:04:57 -0700 (PDT) Received: from [192.168.0.150] (athedsl-4364788.home.otenet.gr. [79.130.9.228]) by mx.google.com with ESMTPS id l26sm18756528fad.17.2011.10.30.06.04.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Oct 2011 06:04:56 -0700 (PDT) Message-ID: <4EAD4B7B.6010807@gmail.com> Date: Sun, 30 Oct 2011 15:04:59 +0200 From: Manolis Kiagias User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "R. Clayton" References: <4EAC4171.1010702@gmail.com> <201110301254.p9UCsLJV004628@rockhopper.monmouth.edu> In-Reply-To: <201110301254.p9UCsLJV004628@rockhopper.monmouth.edu> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8bit Cc: doc@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: docs/162154: [handbook] section 6.4.2 misordering. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 13:04:59 -0000 On 30/10/2011 2:54 ìì, R. Clayton wrote: > Here is a complete patch, also with version information removed: > > Thanks for the quick, and positive, response. I've run across a few other > places in the handbook with reversed ordering; I've written them down > somewhere, but don't remember where. I'll try to find them, and submit them if > they're still relevant. > Thanks for submitting this. The patch will probably be committed later on today. If you do find your notes, we'll be glad to hear from you again. Thanks for helping improve FreeBSD! From owner-freebsd-doc@FreeBSD.ORG Sun Oct 30 13:34:00 2011 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483B8106566B; Sun, 30 Oct 2011 13:34:00 +0000 (UTC) (envelope-from rclayton@monmouth.edu) Received: from mail.monmouth.edu (mail.monmouth.edu [192.100.64.12]) by mx1.freebsd.org (Postfix) with ESMTP id 01ED08FC13; Sun, 30 Oct 2011 13:33:59 +0000 (UTC) Received: from rockhopper.monmouth.edu (rockhopper.monmouth.edu [10.1.13.6]) by mail.monmouth.edu (8.14.4/8.14.4) with ESMTP id p9UCsLxZ023488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Oct 2011 08:54:22 -0400 Received: from rockhopper.monmouth.edu (localhost.localdomain [127.0.0.1]) by rockhopper.monmouth.edu (8.14.4/8.14.4) with ESMTP id p9UCsLKK004629; Sun, 30 Oct 2011 08:54:21 -0400 Received: (from rclayton@localhost) by rockhopper.monmouth.edu (8.14.4/8.14.4/Submit) id p9UCsLJV004628; Sun, 30 Oct 2011 08:54:21 -0400 Date: Sun, 30 Oct 2011 08:54:21 -0400 Message-Id: <201110301254.p9UCsLJV004628@rockhopper.monmouth.edu> X-Authentication-Warning: rockhopper.monmouth.edu: rclayton set sender to rclayton@monmouth.edu using -f From: rclayton@monmouth.edu (R. Clayton) To: Manolis Kiagias In-reply-to: <4EAC4171.1010702@gmail.com> (message from Manolis Kiagias on Sat, 29 Oct 2011 21:09:53 +0300) References: <4EAC4171.1010702@gmail.com> X-Scanned-By: MIMEDefang 2.71 on 192.100.64.12 Cc: doc@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: docs/162154: [handbook] section 6.4.2 misordering. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 13:34:00 -0000 Here is a complete patch, also with version information removed: Thanks for the quick, and positive, response. I've run across a few other places in the handbook with reversed ordering; I've written them down somewhere, but don't remember where. I'll try to find them, and submit them if they're still relevant. From owner-freebsd-doc@FreeBSD.ORG Mon Oct 31 04:28:21 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C139E106566C; Mon, 31 Oct 2011 04:28:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A08F8FC0C; Mon, 31 Oct 2011 04:28:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9V4SLeY048486; Mon, 31 Oct 2011 04:28:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9V4SLom048482; Mon, 31 Oct 2011 04:28:21 GMT (envelope-from linimon) Date: Mon, 31 Oct 2011 04:28:21 GMT Message-Id: <201110310428.p9V4SLom048482@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: docs/162172: rctl manpage erroneously lists nproc X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 04:28:21 -0000 Old Synopsis: rctl manpage lists nproc New Synopsis: rctl manpage erroneously lists nproc Responsible-Changed-From-To: freebsd-bugs->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Mon Oct 31 04:27:09 UTC 2011 Responsible-Changed-Why: Reclassify as a docs problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=162172 From owner-freebsd-doc@FreeBSD.ORG Mon Oct 31 11:06:09 2011 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC9E3106566C for ; Mon, 31 Oct 2011 11:06:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DB5288FC12 for ; Mon, 31 Oct 2011 11:06:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9VB69Vl055998 for ; Mon, 31 Oct 2011 11:06:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9VB68hN055989 for freebsd-doc@FreeBSD.org; Mon, 31 Oct 2011 11:06:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Oct 2011 11:06:08 GMT Message-Id: <201110311106.p9VB68hN055989@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: FreeBSD doc list Cc: Subject: Current unassigned doc problem reports X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 11:06:10 -0000 (Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=doc .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o docs/162172 doc rctl manpage erroneously lists nproc o docs/161804 doc New documentation: French translation for building-pro o docs/161754 doc-bugs p4tcc(4), est(4) and qpi(4) are not documented o docs/161588 doc Missing "-l name" option from pw(8) USER section o docs/161496 doc zfs(1): Please document that sysctl vfs.usermount must o docs/161057 doc [handbook] Error in section 18.17.4 of the handbook o docs/160698 doc Remove outdated FreeBSD Jumpstart guide o docs/160491 doc [patch] reaper of the dead: remove ancient FAQ entries o docs/160447 doc [handbook] Developer's Handbook contains some outdated o docs/160446 doc [handbook] Handbook sound setup seems outdated o docs/160445 doc [handbook] Handbook does not mention ACL o docs/160399 doc Man page for re(4) missing jumbo frames info o docs/160269 doc [patch] Handbook wireless section: sand off some rough o docs/159898 doc [patch] libusb.3 whitespace, markup, grammar fixes o docs/159897 doc [handbook] [patch] improve HAST section of Handbook o docs/159854 doc [patch] grammar updates for carp.4 o docs/159551 doc [patch] ports(7) makes no mention of LOCALBASE o docs/159307 doc [patch] lpd smm chapter unconditionally installed o docs/159298 doc [handbook] document Konqueror with Webkit support to i o docs/158813 doc [patch] grammar updates for jme(4) o docs/158388 doc Incorrect documentation of LOCAL_SCRIPT in release(7) o docs/158387 doc The tree(3) man should mention the RB_FOREACH_SAFE() A o docs/158378 doc cpio/bsdcpio(1) man page does not document -0 and --nu o docs/157908 doc [handbook] Description of post-install should include o docs/157698 doc [patch] gpart(8) man page contains old/incorrect size o docs/157453 doc [patch] document 16-fib cap in setfib.2 o docs/157452 doc [patch] grammar and style nits in ipfw.8 o docs/157337 doc [handbook] [patch] Indentation changes to network serv o docs/157316 doc [patch] update devstat(9) man page o docs/157234 doc [patch] nullfs(5): //proc/curproc/file returns "unknow o docs/157049 doc FreeBSD Handbook: Chapter 14 (Security) Inaccuracy o docs/156955 doc bug in share/man/man2/setsockopt.2 a docs/156920 doc isspecial(3) is not helpful o docs/156815 doc chmod(1): manpage should describe that chmod kicks +t o docs/156689 doc stf(4) output-only documentation gives bad configurati f docs/156187 doc [handbook] [patch] Add bsnmpd to handbook o docs/156081 doc troff falls with troff.core with UTF-8 man with incorr o docs/155989 doc [patch] Fix offset in boot.config(5) o docs/155982 doc [handbook] reaper of the dead: remove reference to flo o docs/155773 doc dialog(1): dialog manpages not updated o docs/155149 doc [patch] don't encourage using xorg.conf outside of PRE o docs/154838 doc update cvs-tags information on releng_* to reflect sup o docs/153958 doc ksu man-page documented, but not installed o docs/153738 doc [patch] Docuement requirement to alter some sysctls wh a docs/153012 doc [patch] iostat(8) requires an argument to -c option o docs/151752 doc pw.conf(5) doesn't define format for file clearly o docs/151367 doc [patch] Update for puc.4 man page o docs/150991 doc [patch] Install upgtfw using pkg_add as advised in upg o docs/150917 doc [patch] icmp.4, wrong description of icmplim and icmpl o docs/150877 doc ambiguity in newsyslog(8) man page about zfs with comp o docs/150365 doc [make.conf] [patch] remove BDECFLAGS from make.conf(5) o docs/150255 doc dtrace description should mention makeoptions DEBUG=-g o docs/150219 doc zfs(8) manual page misses jail/unjail o docs/149574 doc [patch] update mi_switch(9) man page o docs/149522 doc Russian network article: incorrect translation about n o docs/149051 doc [request] No document for clang or clang++ o docs/149047 doc [patch] tcsh(1) bears no mention of brace expansion in o docs/148987 doc [patch] {MD[245]|SHA_|SHA1_|SHA256_}{End|File|FileChun o docs/148984 doc [handbook] Mistake in section 16.15.4 of the handbook o docs/148680 doc [sysctl][patch] Document some sys/kern sysctls o docs/148071 doc Failover mode between wired and wireless interfaces o docs/147995 doc elf.5 man page has has missing reference o docs/146958 doc bad link to "XaQti XMAC II datasheet" in sk(4) manual o docs/146521 doc [handbook] Update IPv6 system handbook section to ment o docs/145719 doc [patch] 7.3 relnotes erroneously describes new getpage o docs/145699 doc hexdump(1) mutes all format qualifier output following o docs/145644 doc Add artical about creating manpage from scratch o docs/145069 doc Dialup firewalling with FreeBSD article out dated. o docs/145066 doc Update for new uart dev names for serial port. s docs/144818 doc all mailinglist archives dated 19970101 contain traili o docs/144630 doc [patch] domainname(1) manpage contains old information o docs/144537 doc Missing _mdconfig_list and _mdconfig2_list explanation o docs/144515 doc [handbook] Expand handbook Table of contents o docs/144488 doc share/examples/etc/make.conf: contains dangerous examp o docs/143850 doc procfs(5) manpage for status > controlling terminal is o docs/143416 doc [handbook] IPFW handbook page issues o docs/143408 doc man filedesc(9) is missing o docs/142168 doc [patch] ld(1): ldd(1) not mentioned in ld(1) manpage o docs/141032 doc misleading documentation for rtadvd.conf(5) raflags se s docs/140847 doc [request] add documentation on ECMP and new route args p docs/140457 doc [patch] Grammar fix for isspace(3) o docs/140444 doc [patch] New Traditional Chinese translation of custom- o docs/140375 doc [UPDATE] Updated zh_TW.Big5/articles/nanobsd o docs/139336 doc [request] ZFS documentation suggestion o docs/139165 doc gssapi.3 man page out of sync with between crypto and o docs/139018 doc translation of submitting.sgml from docproj/submitting o docs/138845 doc Exceeding kern.ipc.maxpipekva refers to tuning(7) whic o docs/138663 doc system(3) man page confuses users about "return value o docs/138485 doc bpf(4) and ip(4) man pages missing important corner ca o docs/136712 doc [handbook] [patch] draft new section on gmirror per pa o docs/136666 doc [handbook] Configure serial port for remote kernel deb o docs/136035 doc ftpchroot(5) omits an important option o docs/135516 doc [patch] pax(1) manual not mentioning chflags unawarene o docs/135475 doc [patch] jot(1) manpage and behaviour differ o docs/134123 doc The RUNQUEUE(9) man page is out of date o docs/132839 doc [patch] Fix example script in ldap-auth article o docs/132718 doc [handbook] Information about adding a new mirror is ou o docs/132260 doc dhcpd(8) pid not stored in documented location o docs/132190 doc EPERM explanation for send(2), sendto(2), and sendmsg( o docs/131918 doc [patch] Fixes for the BPF(4) man page o docs/131626 doc [patch] dump(8) "recommended" cache option confusing o docs/130238 doc nfs.lockd man page doesn't mention NFSLOCKD option or o docs/129671 doc New TCP chapter for Developer's Handbook (from rwatson o docs/129464 doc using packages system o docs/129095 doc ipfw(8): Can not check that packet originating/destine s docs/128356 doc [request] add Firefox plugin for FreeBSD manual pages o docs/127908 doc [patch] readdir(3) error documentation s docs/127844 doc Example code skeleton_capture_n.c in meteor(4) manpage o docs/126590 doc [patch] Write routine called forever in Sample Echo Ps o docs/126484 doc libc function res-zonscut2 is not documented o docs/125921 doc lpd(8) talks about blocks in minfree while it is KB in f docs/122052 doc minor update on handbook section 20.7.1 o docs/121952 doc Handbook chapter on Network Address Translation wrong o docs/121585 doc [handbook] Wrong multicast specification s docs/121541 doc [request] no man pages for wlan_scan_ap o docs/121312 doc RELNOTES_LANG breaks release if not en_US.ISO8859-1 o docs/121173 doc [patch] mq_getattr(2): mq_flags mistakenly described a s docs/120917 doc [request]: Man pages mising for thr_xxx syscalls o docs/120539 doc Inconsistent ipfw's man page o docs/120125 doc [patch] Installing FreeBSD 7.0 via serial console and o docs/120024 doc resolver(5) and hosts(5) need updated for IPv6 o docs/119545 doc books/arch-handbook/usb/chapter.sgml formatting o docs/118902 doc [patch] wrong signatures in d2i_RSAPublicKey man pages o docs/118214 doc close(2) error returns incomplete o docs/118020 doc ipfilter(4): man pages query for man 4 ipfilter return o docs/116116 doc mktemp (3) re/move note o docs/116080 doc PREFIX is documented, but not the more important LOCAL p docs/115065 doc [patch] sync ps.1 with p_flag and keywords o docs/114371 doc [patch] [ip6] rtadvd.con(5) should show how to adverti o docs/114139 doc mbuf(9) has misleading comments on M_DONTWAIT and M_TR o docs/113194 doc [patch] [request] crontab.5: handling of day-in-month o docs/112804 doc groff(1) command should be called to explicitly use "p o docs/112682 doc Handbook GEOM_GPT explanation does not provide accurat o docs/111425 doc Missing chunks of text in historical manpages o docs/111265 doc [request] Clarify how to set common shell variables o docs/111147 doc hostapd.conf is not documented o docs/110999 doc carp(4) should document unsupported interface types o docs/110692 doc wi(4) man page doesn't say WPA is not supported o docs/110376 doc [patch] add some more explanations for the iwi/ipw fir o docs/110253 doc [patch] rtprio(1): remove processing starvation commen o docs/110062 doc [patch] mount_nfs(8) fails to mention a failure condit p docs/110061 doc [patch] tuning(7) missing reference to vfs.read_max o docs/109981 doc No manual entry for post-grohtml o docs/109977 doc No manual entry for ksu o docs/109973 doc No manual entry for c++filt o docs/109972 doc No manual entry for zless/bzless f docs/109226 doc [request] No manual entry for sntp o docs/109201 doc [request]: manual for callbootd a docs/108980 doc list of missing man pages o docs/106135 doc [request] articles/vinum needs to be updated o docs/105608 doc fdc(4) debugging description staled o docs/104879 doc Howto: Listen to IMA ADPCM .wav files on FreeBSD box o docs/102719 doc [patch] ng_bpf(4) example leads to unneeded promiscuos o docs/100196 doc man login.conf does explain not "unlimited" o docs/99506 doc FreeBSD Handbook addition: IPv6 Server Settings o docs/98974 doc Missing tunables in loader(8) manpage o docs/98115 doc Missing parts after rendering handbook to RTF format o docs/96207 doc Comments of a sockaddr_un structure could confuse one o docs/94625 doc [patch] growfs man page -- document "panic: not enough o docs/92626 doc jail manpage should mention disabling some periodic sc o docs/91506 doc ndis(4) man page should be more specific about support o docs/91149 doc read(2) can return EINVAL for unaligned access to bloc o docs/88512 doc [patch] mount_ext2fs(8) man page has no details on lar o docs/87936 doc Handbook chapter on NIS/YP lacks good information on a o docs/87857 doc ifconfig(8) wireless options order matters o docs/85128 doc [patch] loader.conf(5) autoboot_delay incompletly desc o docs/84956 doc [patch] intro(5) manpage doesn't mention API coverage o docs/84932 doc new document: printing with an Epson ALC-3000N on Free o docs/84670 doc [patch] tput(1) manpage missing ENVIRONMENT section wi o docs/84317 doc fdp-primer doesn't show class=USERNAME distinctively o docs/84271 doc [patch] compress(1) doesn't warn about nasty link hand o docs/83820 doc getino(3) manpage not installed o docs/81611 doc [patch] natd runs with -same_ports by default o docs/78480 doc Networked printer setup unnecessarily complex in handb o docs/61605 doc [request] Improve documentation for i386 disk geometry o docs/61301 doc [patch] Manpage patch for aue(4) to enable HomePNA fun o docs/59835 doc ipfw(8) man page does not warn about accepted but mean o docs/59477 doc Outdated Info Documents at http://docs.freebsd.org/inf o docs/59044 doc [patch] doc.docbook.mk does not properly handle a sour o docs/57298 doc [patch] add using compact flash cards info to handbook s docs/54752 doc bus_dma explained in ISA section in Handbook: should b o docs/53751 doc bus_dma(9) incorrectly documents BUS_DMA_ALLOCNOW o docs/53596 doc Updates to mt(1) manual page o docs/53271 doc bus_dma(9) fails to document alignment restrictions o docs/51480 doc Multiple undefined references in the FreeBSD manual pa o docs/50211 doc [patch] doc.docbook.mk: fix textfile creation o docs/48101 doc [patch] Add documentation on the fixit disk o docs/43823 doc [patch] update to environ(7) manpage o docs/41089 doc pax(1) -B option does not mention interaction with -z o docs/40423 doc Keyboard(4)'s definition of parameters to GETFKEY/SETF o docs/38982 doc [patch] developers-handbook/Jail fix o docs/38556 doc EPS file of beastie, as addition to existing examples s docs/35678 doc docproj Makefiles for web are broken for paths with sp s docs/33589 doc [patch] to doc.docbook.mk to post process .tex files. a docs/30008 doc [patch] French softupdates document should be translat o docs/27605 doc [patch] Cross-document references () o docs/26286 doc *printf(3) etc should gain format string warnings o docs/24786 doc missing FILES descriptions in sa(4) s docs/20028 doc ASCII docs should reflect tags in the sourc 199 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon Oct 31 23:40:15 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBE09106564A for ; Mon, 31 Oct 2011 23:40:15 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5E48FC08 for ; Mon, 31 Oct 2011 23:40:15 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p9VNeEAk009091 for ; Mon, 31 Oct 2011 17:40:14 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p9VNeEt0009088 for ; Mon, 31 Oct 2011 17:40:14 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 31 Oct 2011 17:40:14 -0600 (MDT) From: Warren Block To: freebsd-doc@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 31 Oct 2011 17:40:15 -0600 (MDT) Subject: Happy birthday, docs/45303! X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:40:15 -0000 Dear docs/45303, It seems like only yesterday that I noticed you liked to run like a lemming all the way to the right border of the page and then jump off the precipice. I wrote about it in http://www.freebsd.org/cgi/query-pr.cgi?pr=45303 Your parents, SGML and XSL (and uncle TeX!) were sure it was just a phase, not some kind of balance problem, and that you'd grow out of it eventually. Now here it is, only two weeks until your ninth birthday. Happy birthday! Instead of a traditional gift, I've decided to ask a group of experts to help diagnose and hopefully solve your sprinting-off-to-the-right and leaping-off-the-edge problem. For an example, I'll show them the table on page 12 of ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/fdp-primer/book.pdf.bz2 It's a pretty technical problem, but these people are very sharp and care about details and correctness. Don't be embarrassed! If any of them is familiar with the stylesheets and rendering methods, they might be able to take a look and make suggestions, or it may be one of those things where someone with just the right expertise leans in and says "oh, sure, just do this" and it's fixed. Or maybe it's not something that can be fixed. That's okay too, everyone has things they have to learn to live with. I've also enclosed the traditional gift for other people's nine-year-olds... a really loud whistle. Happy birthday! From owner-freebsd-doc@FreeBSD.ORG Tue Nov 1 22:01:24 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3F9A10656D4 for ; Tue, 1 Nov 2011 22:01:24 +0000 (UTC) (envelope-from raj@webphotons.com) Received: from www.mysmallbusinesscircle.com (www.mysmallbusinesscircle.com [50.56.33.54]) by mx1.freebsd.org (Postfix) with ESMTP id 77B6F8FC1B for ; Tue, 1 Nov 2011 22:01:24 +0000 (UTC) Received: from www.mysmallbusinesscircle.com (localhost [127.0.0.1]) by www.mysmallbusinesscircle.com (8.13.8/8.13.8) with ESMTP id pA1KTxge005478 for ; Tue, 1 Nov 2011 16:29:59 -0400 Received: (from apache@localhost) by www.mysmallbusinesscircle.com (8.13.8/8.13.8/Submit) id pA1KTxNj005477; Tue, 1 Nov 2011 16:29:59 -0400 Date: Tue, 1 Nov 2011 16:29:59 -0400 Message-Id: <201111012029.pA1KTxNj005477@www.mysmallbusinesscircle.com> To: " " From: "M.K. Raj" MIME-Version: 1.0 Content-Type: multipart/related; boundary="=====================_61786218==.ALT" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Are you taking on new clients? X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:01:24 -0000 This is a multi-part message in MIME format. --=====================_61786218==.ALT Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit If you're taking on new clients, I'd like to include you in my private referral network to send you business leads through Referral Key. Please accept my invitation below. Thanks! Best, M.K. Raj Web Photons http://www.mysmallbusinesscircle.com/accept.php?i=7534187O7529971Oaf8010&t=1320179399 http://www.mysmallbusinesscircle.com/accept.php?i=7534187O7529971Oaf8010&t=1320179399 --=====================_61786218==.ALT-- From owner-freebsd-doc@FreeBSD.ORG Wed Nov 2 18:21:32 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 421FE106566B; Wed, 2 Nov 2011 18:21:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F29358FC12; Wed, 2 Nov 2011 18:21:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A29C246B2A; Wed, 2 Nov 2011 14:21:31 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2FF378A02E; Wed, 2 Nov 2011 14:21:31 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Wed, 2 Nov 2011 14:21:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> In-Reply-To: <4EABB0AB.9070808@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111021421.30777.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 02 Nov 2011 14:21:31 -0400 (EDT) Cc: "Simon L. B. Nielsen" , freebsd-doc@freebsd.org, doc@freebsd.org, doceng@freebsd.org, =?iso-8859-1?q?Sp=F6rlein?= Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:21:32 -0000 On Saturday, October 29, 2011 3:52:11 am Doug Barton wrote: > On 10/25/2011 11:05, John Baldwin wrote: > > Are you foreseeing having re@ add extra steps to do a fixup so that, say, > > you do 'svn cp doc releng/9.0/doc' or 'svn cp doc release/9.0/doc' after the > > initial copy? > > No, that would be silly. :) Something more along the lines of: > > svn cp doc/foo/bar release/9.0-doc Ok, that would work, though it's a bit hackish. :-P > I don't see any value in duplicating the src process line by line, only > the bits that are relevant. The point was that if you were going to call it release/9.0/doc instead (which is the "logical" name for our current branching scheme) you would have to engage in careful coordination. > > I also think it might do some very bizarre things in our downstream CVS repo > > (or possibly require substantial hackery to our existing SVN -> CVS > > conversion scripts). > > If that turns out to be true then obviously we need to figure out the > right way to handle it. Correct. Mostly we just have to think about this before making any changes to make sure whatever is done doesn't break CVS. > > Keep in mind that we don't have an svn replacement for > > cvsup (esp. in checkout mode) which many users still depend on, so we can't > > just ignore that entirely (though perhaps we could choose to not replicate > > the release version of docs to CVS, or tolerate them showing up as 'src/doc' > > in CVS instead). However we'd need to think about the full implications of > > doing any approach in this regard. > > I'm not sure we need to duplicate all the features we have for cvs in an > svn world. We haven't needed to do that for src, so saying "we need to > solve this for doc" in this context is a red herring. Err, no, that's not what I said. What I said was that src in SVN is not as feature complete as CVS (cvsup), so src has to maintain CVS until that problem is solved. Thus, we can't just ignore the CVS tree and trash it through ignorance. Instead, we have to make sure that things that we do in SVN don't kill CVS. > >> The question is not how can we continue to do what we've always done, > >> but how can we do better? > > > > But the solution has to actually be better. I thinking having docs in SVN vs > > CVS might be better (changesets, etc.), but I'm not convinced that having them > > in the same SVN as src is any better than a dedicated repository. > > And my point is that having them in the same repo is certainly no worse, > and gives us the opportunity to do something better. I am still not convinced it will really buy anything better, but on that we'll just have to disagree. > > However, if the plan is to allow concurrent changes to manpages and docs > > (which can be a valid reason to merge), then you can get the odd behavior > > where revision N of a doc file is "older" than revision M (where M < N) > > of some change in a manpage and if you are walking back in history > > because you are investigating a change in the future made to both files > > that might be a bit confusing. > > I can see how what you're describing could happen, but I don't see why > anyone would care. If you're updating a file in the doc tree in the same > change set as a file in the src tree, the numbers of the current > revisions of the files are (almost certainly) going to be different. The > fact that the revision number for a file which is chronologically older > is numerically higher than the other is a useless piece of trivia. In the case of docs that might be true. However, I have frequently been using annotate on one file in src and needed to align when a change occurred with another file. In fact, I just did this Monday trying to figure out the history of the 'wcommitsize' not-quite-implemented mount option for NFS as I was comparing the histories of both the in-kernel NFS client bits and the mount_nfs program. Maybe you never use annotate, but other people _do_. In the case of docs though, I have not specifically used annotate to the same level of detail as src, but I wouldn't want to presume that people may not have that same need in the future. If you really want to do this in the same repo, I won't object. However, you do need to talk to the SVN/CVS admins first to make sure we don't blow up the CVS repo in unexpected ways, and to decide if you want to propagate any of the changes from SVN to CVS (it might be nice to preserve the "head" of docs in CVS, but it might also not be necessary as cvsup probably isn't that relevant for docs). -- John Baldwin From owner-freebsd-doc@FreeBSD.ORG Wed Nov 2 18:21:32 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 421FE106566B; Wed, 2 Nov 2011 18:21:32 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F29358FC12; Wed, 2 Nov 2011 18:21:31 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A29C246B2A; Wed, 2 Nov 2011 14:21:31 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2FF378A02E; Wed, 2 Nov 2011 14:21:31 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Wed, 2 Nov 2011 14:21:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> In-Reply-To: <4EABB0AB.9070808@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201111021421.30777.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 02 Nov 2011 14:21:31 -0400 (EDT) Cc: "Simon L. B. Nielsen" , freebsd-doc@freebsd.org, doc@freebsd.org, doceng@freebsd.org, =?iso-8859-1?q?Sp=F6rlein?= Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 18:21:32 -0000 On Saturday, October 29, 2011 3:52:11 am Doug Barton wrote: > On 10/25/2011 11:05, John Baldwin wrote: > > Are you foreseeing having re@ add extra steps to do a fixup so that, say, > > you do 'svn cp doc releng/9.0/doc' or 'svn cp doc release/9.0/doc' after the > > initial copy? > > No, that would be silly. :) Something more along the lines of: > > svn cp doc/foo/bar release/9.0-doc Ok, that would work, though it's a bit hackish. :-P > I don't see any value in duplicating the src process line by line, only > the bits that are relevant. The point was that if you were going to call it release/9.0/doc instead (which is the "logical" name for our current branching scheme) you would have to engage in careful coordination. > > I also think it might do some very bizarre things in our downstream CVS repo > > (or possibly require substantial hackery to our existing SVN -> CVS > > conversion scripts). > > If that turns out to be true then obviously we need to figure out the > right way to handle it. Correct. Mostly we just have to think about this before making any changes to make sure whatever is done doesn't break CVS. > > Keep in mind that we don't have an svn replacement for > > cvsup (esp. in checkout mode) which many users still depend on, so we can't > > just ignore that entirely (though perhaps we could choose to not replicate > > the release version of docs to CVS, or tolerate them showing up as 'src/doc' > > in CVS instead). However we'd need to think about the full implications of > > doing any approach in this regard. > > I'm not sure we need to duplicate all the features we have for cvs in an > svn world. We haven't needed to do that for src, so saying "we need to > solve this for doc" in this context is a red herring. Err, no, that's not what I said. What I said was that src in SVN is not as feature complete as CVS (cvsup), so src has to maintain CVS until that problem is solved. Thus, we can't just ignore the CVS tree and trash it through ignorance. Instead, we have to make sure that things that we do in SVN don't kill CVS. > >> The question is not how can we continue to do what we've always done, > >> but how can we do better? > > > > But the solution has to actually be better. I thinking having docs in SVN vs > > CVS might be better (changesets, etc.), but I'm not convinced that having them > > in the same SVN as src is any better than a dedicated repository. > > And my point is that having them in the same repo is certainly no worse, > and gives us the opportunity to do something better. I am still not convinced it will really buy anything better, but on that we'll just have to disagree. > > However, if the plan is to allow concurrent changes to manpages and docs > > (which can be a valid reason to merge), then you can get the odd behavior > > where revision N of a doc file is "older" than revision M (where M < N) > > of some change in a manpage and if you are walking back in history > > because you are investigating a change in the future made to both files > > that might be a bit confusing. > > I can see how what you're describing could happen, but I don't see why > anyone would care. If you're updating a file in the doc tree in the same > change set as a file in the src tree, the numbers of the current > revisions of the files are (almost certainly) going to be different. The > fact that the revision number for a file which is chronologically older > is numerically higher than the other is a useless piece of trivia. In the case of docs that might be true. However, I have frequently been using annotate on one file in src and needed to align when a change occurred with another file. In fact, I just did this Monday trying to figure out the history of the 'wcommitsize' not-quite-implemented mount option for NFS as I was comparing the histories of both the in-kernel NFS client bits and the mount_nfs program. Maybe you never use annotate, but other people _do_. In the case of docs though, I have not specifically used annotate to the same level of detail as src, but I wouldn't want to presume that people may not have that same need in the future. If you really want to do this in the same repo, I won't object. However, you do need to talk to the SVN/CVS admins first to make sure we don't blow up the CVS repo in unexpected ways, and to decide if you want to propagate any of the changes from SVN to CVS (it might be nice to preserve the "head" of docs in CVS, but it might also not be necessary as cvsup probably isn't that relevant for docs). -- John Baldwin From owner-freebsd-doc@FreeBSD.ORG Wed Nov 2 19:36:48 2011 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EA5831065750; Wed, 2 Nov 2011 19:36:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BDAD81A6360; Wed, 2 Nov 2011 19:36:31 +0000 (UTC) Message-ID: <4EB19BBF.70608@FreeBSD.org> Date: Wed, 02 Nov 2011 12:36:31 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> <201111021421.30777.jhb@freebsd.org> In-Reply-To: <201111021421.30777.jhb@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Simon L. B. Nielsen" , freebsd-doc@freebsd.org, doc@freebsd.org, doceng@freebsd.org, =?ISO-8859-1?Q?Sp=F6rlein?= Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 19:36:49 -0000 See, this is why conversation/discussion is a good thing. :) On 11/02/2011 11:21, John Baldwin wrote: > On Saturday, October 29, 2011 3:52:11 am Doug Barton wrote: >> On 10/25/2011 11:05, John Baldwin wrote: >>> Are you foreseeing having re@ add extra steps to do a fixup so that, say, >>> you do 'svn cp doc releng/9.0/doc' or 'svn cp doc release/9.0/doc' after the >>> initial copy? >> >> No, that would be silly. :) Something more along the lines of: >> >> svn cp doc/foo/bar release/9.0-doc > > Ok, that would work, though it's a bit hackish. :-P Sure, but compare base/vendor, and base/vendor-crypto, base/vendor-sys. And/or vendor/bind9/dist, and vendor/bind9/dist-9.N. >> I don't see any value in duplicating the src process line by line, only >> the bits that are relevant. > > The point was that if you were going to call it release/9.0/doc instead > (which is the "logical" name for our current branching scheme) you > would have to engage in careful coordination. Sure, it's logical in one sense, but too painful to do in another. If we can make the paths "pretty" that's a bonus, but "works, with minimal pain" is more important. >>> Keep in mind that we don't have an svn replacement for >>> cvsup (esp. in checkout mode) which many users still depend on, so we can't >>> just ignore that entirely (though perhaps we could choose to not replicate >>> the release version of docs to CVS, or tolerate them showing up as 'src/doc' >>> in CVS instead). However we'd need to think about the full implications of >>> doing any approach in this regard. >> >> I'm not sure we need to duplicate all the features we have for cvs in an >> svn world. We haven't needed to do that for src, so saying "we need to >> solve this for doc" in this context is a red herring. > > Err, no, that's not what I said. What I said was that src in SVN is not as > feature complete as CVS (cvsup), so src has to maintain CVS until that problem > is solved. Thus, we can't just ignore the CVS tree and trash it through > ignorance. Instead, we have to make sure that things that we do in SVN don't > kill CVS. Ok, then I misunderstood you, and I apologize for the red herring accusation. I thought it went without saying that we don't want to break svn->cvs for src, but I'm glad that you're saying it. :) >>>> The question is not how can we continue to do what we've always done, >>>> but how can we do better? >>> >>> But the solution has to actually be better. I thinking having docs in SVN vs >>> CVS might be better (changesets, etc.), but I'm not convinced that having them >>> in the same SVN as src is any better than a dedicated repository. >> >> And my point is that having them in the same repo is certainly no worse, >> and gives us the opportunity to do something better. > > I am still not convinced it will really buy anything better, but on that we'll > just have to disagree. Fair enough. >>> However, if the plan is to allow concurrent changes to manpages and docs >>> (which can be a valid reason to merge), then you can get the odd behavior >>> where revision N of a doc file is "older" than revision M (where M < N) >>> of some change in a manpage and if you are walking back in history >>> because you are investigating a change in the future made to both files >>> that might be a bit confusing. >> >> I can see how what you're describing could happen, but I don't see why >> anyone would care. If you're updating a file in the doc tree in the same >> change set as a file in the src tree, the numbers of the current >> revisions of the files are (almost certainly) going to be different. The >> fact that the revision number for a file which is chronologically older >> is numerically higher than the other is a useless piece of trivia. > > In the case of docs that might be true. However, I have frequently been > using annotate on one file in src and needed to align when a change > occurred with another file. In fact, I just did this Monday trying to figure > out the history of the 'wcommitsize' not-quite-implemented mount option for > NFS as I was comparing the histories of both the in-kernel NFS client bits > and the mount_nfs program. Maybe you never use annotate, but other people > _do_. In the case of docs though, I have not specifically used annotate to > the same level of detail as src, but I wouldn't want to presume that people > may not have that same need in the future. Um, I use annotate all the time. I still don't see see how a higher revision number on a chronologically older document is going to bring about the zombie apocalypse. Yes, it might look "odd" at first, and may take half a second of mental processing the first few times someone sees it. But I think that in a year this will just be "one of those things about the svn transition," just like the fact that successive versions of any given document have dramatically different revision numbers. But now I'm repeating myself (again). > If you really want to do this in the same repo, I won't object. Just to be clear, I personally do think it's the right design choice, sure. But there are also plenty of people who have been talking about the benefits that this would bring. It would be nice if some of those people speak up now. :) Doug > However, > you do need to talk to the SVN/CVS admins first to make sure we don't blow > up the CVS repo in unexpected ways, and to decide if you want to propagate > any of the changes from SVN to CVS (it might be nice to preserve the "head" > of docs in CVS, but it might also not be necessary as cvsup probably isn't > that relevant for docs). -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-doc@FreeBSD.ORG Wed Nov 2 19:36:48 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EA5831065750; Wed, 2 Nov 2011 19:36:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id BDAD81A6360; Wed, 2 Nov 2011 19:36:31 +0000 (UTC) Message-ID: <4EB19BBF.70608@FreeBSD.org> Date: Wed, 02 Nov 2011 12:36:31 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Baldwin References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> <201111021421.30777.jhb@freebsd.org> In-Reply-To: <201111021421.30777.jhb@freebsd.org> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Simon L. B. Nielsen" , freebsd-doc@freebsd.org, doc@freebsd.org, doceng@freebsd.org, =?ISO-8859-1?Q?Sp=F6rlein?= Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 19:36:49 -0000 See, this is why conversation/discussion is a good thing. :) On 11/02/2011 11:21, John Baldwin wrote: > On Saturday, October 29, 2011 3:52:11 am Doug Barton wrote: >> On 10/25/2011 11:05, John Baldwin wrote: >>> Are you foreseeing having re@ add extra steps to do a fixup so that, say, >>> you do 'svn cp doc releng/9.0/doc' or 'svn cp doc release/9.0/doc' after the >>> initial copy? >> >> No, that would be silly. :) Something more along the lines of: >> >> svn cp doc/foo/bar release/9.0-doc > > Ok, that would work, though it's a bit hackish. :-P Sure, but compare base/vendor, and base/vendor-crypto, base/vendor-sys. And/or vendor/bind9/dist, and vendor/bind9/dist-9.N. >> I don't see any value in duplicating the src process line by line, only >> the bits that are relevant. > > The point was that if you were going to call it release/9.0/doc instead > (which is the "logical" name for our current branching scheme) you > would have to engage in careful coordination. Sure, it's logical in one sense, but too painful to do in another. If we can make the paths "pretty" that's a bonus, but "works, with minimal pain" is more important. >>> Keep in mind that we don't have an svn replacement for >>> cvsup (esp. in checkout mode) which many users still depend on, so we can't >>> just ignore that entirely (though perhaps we could choose to not replicate >>> the release version of docs to CVS, or tolerate them showing up as 'src/doc' >>> in CVS instead). However we'd need to think about the full implications of >>> doing any approach in this regard. >> >> I'm not sure we need to duplicate all the features we have for cvs in an >> svn world. We haven't needed to do that for src, so saying "we need to >> solve this for doc" in this context is a red herring. > > Err, no, that's not what I said. What I said was that src in SVN is not as > feature complete as CVS (cvsup), so src has to maintain CVS until that problem > is solved. Thus, we can't just ignore the CVS tree and trash it through > ignorance. Instead, we have to make sure that things that we do in SVN don't > kill CVS. Ok, then I misunderstood you, and I apologize for the red herring accusation. I thought it went without saying that we don't want to break svn->cvs for src, but I'm glad that you're saying it. :) >>>> The question is not how can we continue to do what we've always done, >>>> but how can we do better? >>> >>> But the solution has to actually be better. I thinking having docs in SVN vs >>> CVS might be better (changesets, etc.), but I'm not convinced that having them >>> in the same SVN as src is any better than a dedicated repository. >> >> And my point is that having them in the same repo is certainly no worse, >> and gives us the opportunity to do something better. > > I am still not convinced it will really buy anything better, but on that we'll > just have to disagree. Fair enough. >>> However, if the plan is to allow concurrent changes to manpages and docs >>> (which can be a valid reason to merge), then you can get the odd behavior >>> where revision N of a doc file is "older" than revision M (where M < N) >>> of some change in a manpage and if you are walking back in history >>> because you are investigating a change in the future made to both files >>> that might be a bit confusing. >> >> I can see how what you're describing could happen, but I don't see why >> anyone would care. If you're updating a file in the doc tree in the same >> change set as a file in the src tree, the numbers of the current >> revisions of the files are (almost certainly) going to be different. The >> fact that the revision number for a file which is chronologically older >> is numerically higher than the other is a useless piece of trivia. > > In the case of docs that might be true. However, I have frequently been > using annotate on one file in src and needed to align when a change > occurred with another file. In fact, I just did this Monday trying to figure > out the history of the 'wcommitsize' not-quite-implemented mount option for > NFS as I was comparing the histories of both the in-kernel NFS client bits > and the mount_nfs program. Maybe you never use annotate, but other people > _do_. In the case of docs though, I have not specifically used annotate to > the same level of detail as src, but I wouldn't want to presume that people > may not have that same need in the future. Um, I use annotate all the time. I still don't see see how a higher revision number on a chronologically older document is going to bring about the zombie apocalypse. Yes, it might look "odd" at first, and may take half a second of mental processing the first few times someone sees it. But I think that in a year this will just be "one of those things about the svn transition," just like the fact that successive versions of any given document have dramatically different revision numbers. But now I'm repeating myself (again). > If you really want to do this in the same repo, I won't object. Just to be clear, I personally do think it's the right design choice, sure. But there are also plenty of people who have been talking about the benefits that this would bring. It would be nice if some of those people speak up now. :) Doug > However, > you do need to talk to the SVN/CVS admins first to make sure we don't blow > up the CVS repo in unexpected ways, and to decide if you want to propagate > any of the changes from SVN to CVS (it might be nice to preserve the "head" > of docs in CVS, but it might also not be necessary as cvsup probably isn't > that relevant for docs). -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-doc@FreeBSD.ORG Wed Nov 2 21:49:21 2011 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E2ED106566C; Wed, 2 Nov 2011 21:49:21 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [88.198.49.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6B78FC21; Wed, 2 Nov 2011 21:49:20 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id pA2LQ1S1098414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Nov 2011 22:26:01 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 2 Nov 2011 22:26:00 +0100 From: =?utf-8?B?U3DDtnJsZWlu?= To: Doug Barton Message-ID: <20111102212600.GC26743@acme.spoerlein.net> References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> <201111021421.30777.jhb@freebsd.org> <4EB19BBF.70608@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB19BBF.70608@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Simon L. B. Nielsen" , freebsd-doc@FreeBSD.org, doc@FreeBSD.org, John Baldwin , doceng@FreeBSD.org Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:49:21 -0000 On Wed, 2011-11-02 at 12:36:31 -0700, Doug Barton wrote: > On 11/02/2011 11:21, John Baldwin wrote: > > If you really want to do this in the same repo, I won't object. > > Just to be clear, I personally do think it's the right design choice, > sure. But there are also plenty of people who have been talking about > the benefits that this would bring. It would be nice if some of those > people speak up now. :) 1. One less thing to admin/maintain (and btw, I'm of the opinion we should get rid of the svn->cvs exporter, but that's another can of worms) 2. Changesets spanning source *and* documentation. 3. The possibility to svn mv parts of src into doc and vice versa. Might actually simplify release building, but I'm not familiar with that. 4. Less confusion about what a svn revision number means. With CVS IDs everybody knew it's about a file. If we would have two or three SVN repos, then 'r123456' can mean three wildly different things. 5. There's already more than just source in the svn, namely portmaster and stress2. It would be nice if we could move all the "user" stuff from /projects into /user and have /projects be for non-source stuff like stress2 and portmaster. And while we're at it, we call it 'docproj', so why not stick it under /projects/doc ? (I'm only partially serious about this ...) I'm sure there's more that will only be obvious once we've done the switch. But the actual doc committers have been very silent on this subject lately. Cheers, Uli From owner-freebsd-doc@FreeBSD.ORG Wed Nov 2 21:49:21 2011 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E2ED106566C; Wed, 2 Nov 2011 21:49:21 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [88.198.49.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9D6B78FC21; Wed, 2 Nov 2011 21:49:20 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id pA2LQ1S1098414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Nov 2011 22:26:01 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 2 Nov 2011 22:26:00 +0100 From: =?utf-8?B?U3DDtnJsZWlu?= To: Doug Barton Message-ID: <20111102212600.GC26743@acme.spoerlein.net> References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> <201111021421.30777.jhb@freebsd.org> <4EB19BBF.70608@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB19BBF.70608@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Simon L. B. Nielsen" , freebsd-doc@FreeBSD.org, doc@FreeBSD.org, John Baldwin , doceng@FreeBSD.org Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:49:21 -0000 On Wed, 2011-11-02 at 12:36:31 -0700, Doug Barton wrote: > On 11/02/2011 11:21, John Baldwin wrote: > > If you really want to do this in the same repo, I won't object. > > Just to be clear, I personally do think it's the right design choice, > sure. But there are also plenty of people who have been talking about > the benefits that this would bring. It would be nice if some of those > people speak up now. :) 1. One less thing to admin/maintain (and btw, I'm of the opinion we should get rid of the svn->cvs exporter, but that's another can of worms) 2. Changesets spanning source *and* documentation. 3. The possibility to svn mv parts of src into doc and vice versa. Might actually simplify release building, but I'm not familiar with that. 4. Less confusion about what a svn revision number means. With CVS IDs everybody knew it's about a file. If we would have two or three SVN repos, then 'r123456' can mean three wildly different things. 5. There's already more than just source in the svn, namely portmaster and stress2. It would be nice if we could move all the "user" stuff from /projects into /user and have /projects be for non-source stuff like stress2 and portmaster. And while we're at it, we call it 'docproj', so why not stick it under /projects/doc ? (I'm only partially serious about this ...) I'm sure there's more that will only be obvious once we've done the switch. But the actual doc committers have been very silent on this subject lately. Cheers, Uli From owner-freebsd-doc@FreeBSD.ORG Thu Nov 3 11:51:28 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F7391065673; Thu, 3 Nov 2011 11:51:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 181AE8FC19; Thu, 3 Nov 2011 11:51:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA3BpR2G038061; Thu, 3 Nov 2011 11:51:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA3BpRPB038057; Thu, 3 Nov 2011 11:51:27 GMT (envelope-from linimon) Date: Thu, 3 Nov 2011 11:51:27 GMT Message-Id: <201111031151.pA3BpRPB038057@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-doc@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: docs/162265: [Patch] ipfw.8: Documentation clarity X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:51:28 -0000 Old Synopsis: [Patch] [ipfw.8] Documentation clarity New Synopsis: [Patch] ipfw.8: Documentation clarity Responsible-Changed-From-To: freebsd-bugs->freebsd-doc Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 3 11:51:07 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=162265 From owner-freebsd-doc@FreeBSD.ORG Thu Nov 3 20:10:11 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EAA810656D5 for ; Thu, 3 Nov 2011 20:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5910E8FC16 for ; Thu, 3 Nov 2011 20:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA3KABvC094251 for ; Thu, 3 Nov 2011 20:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA3KABJg094247; Thu, 3 Nov 2011 20:10:11 GMT (envelope-from gnats) Resent-Date: Thu, 3 Nov 2011 20:10:11 GMT Resent-Message-Id: <201111032010.pA3KABJg094247@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Chris Rees Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E8191065670 for ; Thu, 3 Nov 2011 20:07:17 +0000 (UTC) (envelope-from crees@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5A58FC18 for ; Thu, 3 Nov 2011 20:07:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA3K7GJw094174 for ; Thu, 3 Nov 2011 20:07:16 GMT (envelope-from crees@freefall.freebsd.org) Received: (from crees@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA3K7GWA094173; Thu, 3 Nov 2011 20:07:16 GMT (envelope-from crees) Message-Id: <201111032007.pA3K7GWA094173@freefall.freebsd.org> Date: Thu, 3 Nov 2011 20:07:16 GMT From: Chris Rees To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/162275: PR handling guidelines: Mention that Responsible should be gnats-admin for junk X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Chris Rees List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:10:11 -0000 >Number: 162275 >Category: docs >Synopsis: PR handling guidelines: Mention that Responsible should be gnats-admin for junk >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 03 20:10:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Chris Rees >Release: FreeBSD 8.2-STABLE i386 >Organization: >Environment: System: FreeBSD freefall.freebsd.org 8.2-STABLE FreeBSD 8.2-STABLE #4 r220774: Mon Apr 18 13:56:14 UTC 2011 simon@freefall.freebsd.org:/usr/obj/usr/src/sys/FREEFALL i386 >Description: eadler reminded me to set responsible for a junk PR to gnats-admin, so I figure this should be documented here. >How-To-Repeat: >Fix: --- pr-guidelines-junk.diff.txt begins here --- Index: article.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/articles/pr-guidelines/article.sgml,v retrieving revision 1.38 diff -u -r1.38 article.sgml --- article.sgml 1 Sep 2011 16:35:16 -0000 1.38 +++ article.sgml 3 Nov 2011 20:02:11 -0000 @@ -1042,6 +1042,10 @@ + Set Responsible to gnats-admin. + + + Set State to closed. --- pr-guidelines-junk.diff.txt ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Thu Nov 3 20:21:45 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3470E1065672 for ; Thu, 3 Nov 2011 20:21:45 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC6EB8FC20 for ; Thu, 3 Nov 2011 20:21:44 +0000 (UTC) Received: by qadz32 with SMTP id z32so2095992qad.13 for ; Thu, 03 Nov 2011 13:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=5jB8o7CqqEg4D4cDqRDKbVe0/2aoX8xww3ywvldngdc=; b=MZT4pcPP37zVkNfqJYYyvOuJLrrZJBJQbwBIkc08JhxbckMNoJnOQ4FZDVdeu8G48b Hkt1DBj30YgHKcyfp+3+b/jU2f1jeI4/nq9DfpZu+yp47xgDl1xPW0LTrb0Md4mr5wzY lQLX1Pt8CpCJw2iRE+p67Tq0oCJK9XWIUEvOE= Received: by 10.50.36.168 with SMTP id r8mr6647491igj.49.1320351704118; Thu, 03 Nov 2011 13:21:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Thu, 3 Nov 2011 13:21:13 -0700 (PDT) From: Chris Rees Date: Thu, 3 Nov 2011 20:21:13 +0000 Message-ID: To: doc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: FreeBSD developers / committers list X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:21:45 -0000 Hey all, We have a list of developers at [1], and a list of developer alumni at [2] -- they seem a little out of date. As of right now (today), there are ~90 people on that list who aren't listed in any CVSROOT-*/access lists; I'm conscious that most have been Grim Reapered/resigned, and the Alumni page hasn't been updated... Is there a policy on the Alumni page? Is it deliberate that these guys have been left in, or just that no-one has updated the page? Oh, there're also a few guys in access files and not listed in [1]... [4] Chris [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html [2] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/contrib-develalumni.html [3] http://www.bayofrum.net/~crees/lists/developers-list-20111103/alumni_still_developers.txt [4] http://www.bayofrum.net/~crees/lists/developers-list-20111103/undocumented_developers.txt From owner-freebsd-doc@FreeBSD.ORG Thu Nov 3 20:31:10 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CA8A106564A for ; Thu, 3 Nov 2011 20:31:10 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E39018FC17 for ; Thu, 3 Nov 2011 20:31:09 +0000 (UTC) Received: by ywt32 with SMTP id 32so2265976ywt.13 for ; Thu, 03 Nov 2011 13:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=LsK813YRQ9ZiyxxuBvknHNXiMUASLaHQeMIsPlRQXdM=; b=Lz/+PcEZ3gqp9cwwmEwtCJKGA3ix2DMT7fr6mrB1jyjsttzJYg03/4sIhWfuKbjOo0 wq0+4fFgGYarg/NsWuuHC+LOGuYX1nXYGYaFfHt7JocamAqPvilCmT6TGT4MzwGhEZB9 +XgmV0E6XFn8xjr5qrMD3EMqgBPxcjTPeuh/0= Received: by 10.50.36.168 with SMTP id r8mr6693268igj.49.1320352269139; Thu, 03 Nov 2011 13:31:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Thu, 3 Nov 2011 13:30:38 -0700 (PDT) In-Reply-To: References: From: Chris Rees Date: Thu, 3 Nov 2011 20:30:38 +0000 Message-ID: To: doc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: FreeBSD developers / committers list X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:31:10 -0000 On 3 November 2011 20:21, Chris Rees wrote: > Hey all, > > We have a list of developers at [1], and a list of developer alumni at > [2] -- they seem a little out of date. =A0As of right now (today), there > are ~90 people on that list who aren't listed in any CVSROOT-*/access > lists; I'm conscious that most have been Grim Reapered/resigned, and > the Alumni page hasn't been updated... > > Is there a policy on the Alumni page? Is it deliberate that these guys > have been left in, or just that no-one has updated the page? > > Oh, there're also a few guys in access files and not listed in [1]... [4] > > Chris > > > [1] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staf= f-committers.html > > [2] http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/cont= rib-develalumni.html > > [3] http://www.bayofrum.net/~crees/lists/developers-list-20111103/alumni_= still_developers.txt > > [4] http://www.bayofrum.net/~crees/lists/developers-list-20111103/undocum= ented_developers.txt Following a concern sent privately to me, yes, using CVSROOT-src/access to check commit bit status is still valid :) It's still exported from svnadmin/access. Chris From owner-freebsd-doc@FreeBSD.ORG Thu Nov 3 20:51:04 2011 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC75B106566C; Thu, 3 Nov 2011 20:51:04 +0000 (UTC) (envelope-from manolis@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B423E8FC19; Thu, 3 Nov 2011 20:51:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id pA3Kp4aR041049; Thu, 3 Nov 2011 20:51:04 GMT (envelope-from manolis@freefall.freebsd.org) Received: (from manolis@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id pA3Kp4Pj041038; Thu, 3 Nov 2011 20:51:04 GMT (envelope-from manolis) Date: Thu, 3 Nov 2011 20:51:04 GMT Message-Id: <201111032051.pA3Kp4Pj041038@freefall.freebsd.org> To: manolis@FreeBSD.org, freebsd-doc@FreeBSD.org, manolis@FreeBSD.org From: manolis@FreeBSD.org Cc: Subject: Re: docs/162275: PR handling guidelines: Mention that Responsible should be gnats-admin for junk X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:51:04 -0000 Synopsis: PR handling guidelines: Mention that Responsible should be gnats-admin for junk Responsible-Changed-From-To: freebsd-doc->manolis Responsible-Changed-By: manolis Responsible-Changed-When: Thu Nov 3 20:50:25 UTC 2011 Responsible-Changed-Why: Over to me http://www.freebsd.org/cgi/query-pr.cgi?pr=162275 From owner-freebsd-doc@FreeBSD.ORG Thu Nov 3 21:37:01 2011 Return-Path: Delivered-To: freebsd-doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B850106564A; Thu, 3 Nov 2011 21:37:01 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxout1.bln1.prohost.de (mxout1.bln1.prohost.de [213.160.84.47]) by mx1.freebsd.org (Postfix) with ESMTP id EA23B8FC13; Thu, 3 Nov 2011 21:37:00 +0000 (UTC) Received: from Benedicts-Macbook-Pro.local (p4FC72226.dip.t-dialin.net [79.199.34.38]) (authenticated bits=0) by mx1.bln1.prohost.de (8.14.1/8.14.1) with ESMTP id pA3LaphL018199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2011 22:36:52 +0100 Message-ID: <4EB3097A.5080506@FreeBSD.org> Date: Thu, 03 Nov 2011 22:36:58 +0100 From: Benedict Reuschling Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sp=F6rlein?= References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> <201111021421.30777.jhb@freebsd.org> <4EB19BBF.70608@FreeBSD.org> <20111102212600.GC26743@acme.spoerlein.net> In-Reply-To: <20111102212600.GC26743@acme.spoerlein.net> X-Enigmail-Version: 1.3.2 OpenPGP: id=4A819348 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Null-Tag: 794ac18cdcf2b84d00dcf1966517a3ea Cc: Doug Barton , doc@FreeBSD.org, John Baldwin , doceng@FreeBSD.org, freebsd-doc@FreeBSD.org, "Simon L. B. Nielsen" Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bcr@FreeBSD.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:37:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.11.11 22:26, schrieb Spörlein: > On Wed, 2011-11-02 at 12:36:31 -0700, Doug Barton wrote: >> On 11/02/2011 11:21, John Baldwin wrote: >>> If you really want to do this in the same repo, I won't object. >> >> Just to be clear, I personally do think it's the right design choice, >> sure. But there are also plenty of people who have been talking about >> the benefits that this would bring. It would be nice if some of those >> people speak up now. :) > > 1. One less thing to admin/maintain (and btw, I'm of the opinion we > should get rid of the svn->cvs exporter, but that's another can of > worms) > > 2. Changesets spanning source *and* documentation. > > 3. The possibility to svn mv parts of src into doc and vice versa. Might > actually simplify release building, but I'm not familiar with that. > > 4. Less confusion about what a svn revision number means. With CVS IDs > everybody knew it's about a file. If we would have two or three SVN > repos, then 'r123456' can mean three wildly different things. > Indeed, but we agreed (more or less) that we should put ports into a separate repo (once they do the actual conversion). So even if we agreed on putting doc and src together into one repo, there will still be ambiguity about which revision number has been referred to: the doc+src one or the one in the ports repo, right. ;) Speaking of the ports repo: I remember (correct me if I'm wrong) that a portion of the ports repository (or certain ports within it) is required to build the handbook, so there is already a more or less tightly knit connection between the doc and the ports repo. If we want to make things better (which we should), then we might want to take this fact into account. > 5. There's already more than just source in the svn, namely portmaster > and stress2. It would be nice if we could move all the "user" stuff from > /projects into /user and have /projects be for non-source stuff like > stress2 and portmaster. > > And while we're at it, we call it 'docproj', so why not stick it under > /projects/doc ? (I'm only partially serious about this ...) > > I'm sure there's more that will only be obvious once we've done the > switch. But the actual doc committers have been very silent on this > subject lately. > Well, I for one (welcome our new SVN overlords) have been watching the discussion that unfolded with a keen interest. It seems that there are as much arguments for/against a combined doc+src repo as well as for keeping them separate (and vice versa). From my point of view, I could live with both. However, I remember one thing from my (otherwise very boring) distributed systems lecture back when I was a student: If you are not sure whether to distribute or not, then it is better to distribute, rather than figuring it out afterwards, because it then becomes more messy to divide things again. Something like that, I don't know if that is of any help here (but this would mean separate repos then). I just want to have the SVN migration get underway sooner than later, given all the time it requires to make the transition, of course. Cutting off CVS (no svn2cvs export required IMO) and get back to work, since the next big thing(tm) would be the switch to DocBook XML, which we agreed at the EuroBSDcon DevSummit doc session should come afterwards. Doceng wanted to work on this issue further, but I guess they are busy with release work. Has anyone else some ideas to contribute? Regards Benedict Reuschling FreeBSD Documentation Committer The FreeBSD Documentation Project FreeBSD German Documentation Project - https://doc.bsdgroup.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6zCXoACgkQTSZQLkqBk0jHnACeP01eLdTSzYmhLvWuTQ3kryXG SJQAn3tX+4bh4qoiZYou/9Da7vYlQMCy =+mCE -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Thu Nov 3 21:47:51 2011 Return-Path: Delivered-To: doc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8046A1065677; Thu, 3 Nov 2011 21:47:51 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxout1.bln1.prohost.de (mxout1.bln1.prohost.de [213.160.84.47]) by mx1.freebsd.org (Postfix) with ESMTP id 07E788FC15; Thu, 3 Nov 2011 21:47:50 +0000 (UTC) Received: from Benedicts-Macbook-Pro.local (p4FC72226.dip.t-dialin.net [79.199.34.38]) (authenticated bits=0) by mx1.bln1.prohost.de (8.14.1/8.14.1) with ESMTP id pA3LaphL018199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2011 22:36:52 +0100 Message-ID: <4EB3097A.5080506@FreeBSD.org> Date: Thu, 03 Nov 2011 22:36:58 +0100 From: Benedict Reuschling Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sp=F6rlein?= References: <20111007141312.GJ26743@acme.spoerlein.net> <201110251405.46493.jhb@freebsd.org> <4EABB0AB.9070808@FreeBSD.org> <201111021421.30777.jhb@freebsd.org> <4EB19BBF.70608@FreeBSD.org> <20111102212600.GC26743@acme.spoerlein.net> In-Reply-To: <20111102212600.GC26743@acme.spoerlein.net> X-Enigmail-Version: 1.3.2 OpenPGP: id=4A819348 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Null-Tag: 794ac18cdcf2b84d00dcf1966517a3ea Cc: Doug Barton , doc@FreeBSD.org, John Baldwin , doceng@FreeBSD.org, freebsd-doc@FreeBSD.org, "Simon L. B. Nielsen" Subject: Re: Conversion to SVN X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bcr@FreeBSD.org List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:47:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.11.11 22:26, schrieb Spörlein: > On Wed, 2011-11-02 at 12:36:31 -0700, Doug Barton wrote: >> On 11/02/2011 11:21, John Baldwin wrote: >>> If you really want to do this in the same repo, I won't object. >> >> Just to be clear, I personally do think it's the right design choice, >> sure. But there are also plenty of people who have been talking about >> the benefits that this would bring. It would be nice if some of those >> people speak up now. :) > > 1. One less thing to admin/maintain (and btw, I'm of the opinion we > should get rid of the svn->cvs exporter, but that's another can of > worms) > > 2. Changesets spanning source *and* documentation. > > 3. The possibility to svn mv parts of src into doc and vice versa. Might > actually simplify release building, but I'm not familiar with that. > > 4. Less confusion about what a svn revision number means. With CVS IDs > everybody knew it's about a file. If we would have two or three SVN > repos, then 'r123456' can mean three wildly different things. > Indeed, but we agreed (more or less) that we should put ports into a separate repo (once they do the actual conversion). So even if we agreed on putting doc and src together into one repo, there will still be ambiguity about which revision number has been referred to: the doc+src one or the one in the ports repo, right. ;) Speaking of the ports repo: I remember (correct me if I'm wrong) that a portion of the ports repository (or certain ports within it) is required to build the handbook, so there is already a more or less tightly knit connection between the doc and the ports repo. If we want to make things better (which we should), then we might want to take this fact into account. > 5. There's already more than just source in the svn, namely portmaster > and stress2. It would be nice if we could move all the "user" stuff from > /projects into /user and have /projects be for non-source stuff like > stress2 and portmaster. > > And while we're at it, we call it 'docproj', so why not stick it under > /projects/doc ? (I'm only partially serious about this ...) > > I'm sure there's more that will only be obvious once we've done the > switch. But the actual doc committers have been very silent on this > subject lately. > Well, I for one (welcome our new SVN overlords) have been watching the discussion that unfolded with a keen interest. It seems that there are as much arguments for/against a combined doc+src repo as well as for keeping them separate (and vice versa). From my point of view, I could live with both. However, I remember one thing from my (otherwise very boring) distributed systems lecture back when I was a student: If you are not sure whether to distribute or not, then it is better to distribute, rather than figuring it out afterwards, because it then becomes more messy to divide things again. Something like that, I don't know if that is of any help here (but this would mean separate repos then). I just want to have the SVN migration get underway sooner than later, given all the time it requires to make the transition, of course. Cutting off CVS (no svn2cvs export required IMO) and get back to work, since the next big thing(tm) would be the switch to DocBook XML, which we agreed at the EuroBSDcon DevSummit doc session should come afterwards. Doceng wanted to work on this issue further, but I guess they are busy with release work. Has anyone else some ideas to contribute? Regards Benedict Reuschling FreeBSD Documentation Committer The FreeBSD Documentation Project FreeBSD German Documentation Project - https://doc.bsdgroup.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6zCXoACgkQTSZQLkqBk0jHnACeP01eLdTSzYmhLvWuTQ3kryXG SJQAn3tX+4bh4qoiZYou/9Da7vYlQMCy =+mCE -----END PGP SIGNATURE----- From owner-freebsd-doc@FreeBSD.ORG Fri Nov 4 14:59:05 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 330B6106566B for ; Fri, 4 Nov 2011 14:59:05 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 921B08FC13 for ; Fri, 4 Nov 2011 14:59:04 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 73958E3F07A; Fri, 4 Nov 2011 15:43:04 +0100 (CET) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvz9VwFBy821; Fri, 4 Nov 2011 15:43:02 +0100 (CET) Received: from goofy01.vnodelab.local (unknown [212.247.52.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id F01B8E3F079; Fri, 4 Nov 2011 15:43:01 +0100 (CET) Date: Fri, 4 Nov 2011 15:43:00 +0100 From: Joel Dahl To: Chris Rees Message-ID: <20111104144300.GF83971@goofy01.vnodelab.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: doc@freebsd.org Subject: Re: FreeBSD developers / committers list X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:59:05 -0000 On 03-11-2011 20:21, Chris Rees wrote: > Hey all, > > We have a list of developers at [1], and a list of developer alumni at > [2] -- they seem a little out of date. As of right now (today), there > are ~90 people on that list who aren't listed in any CVSROOT-*/access > lists; I'm conscious that most have been Grim Reapered/resigned, and > the Alumni page hasn't been updated... > > Is there a policy on the Alumni page? Is it deliberate that these guys > have been left in, or just that no-one has updated the page? No-one has updated it. I kept it updated for a few years, but not anymore. I was hoping someone would grab it. If you want to update it, please go ahead. -- Joel From owner-freebsd-doc@FreeBSD.ORG Fri Nov 4 15:30:43 2011 Return-Path: Delivered-To: doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFC81065679 for ; Fri, 4 Nov 2011 15:30:43 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 69AAA8FC25 for ; Fri, 4 Nov 2011 15:30:43 +0000 (UTC) Received: by qyk9 with SMTP id 9so2331347qyk.13 for ; Fri, 04 Nov 2011 08:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=xK4/GgA80++SenxT+ZQCa+NJh+2qM65DP2RVqfgnIAA=; b=mljMWlDouYL4ukWlhazN8hX8YRN/Zf3rNfP5T05pSnPYIX6sPjQYjF05bjYbc7gFtx 9ntoYbmg9dvYD/K623Vfb6hjz6BCqp24UgNqy1COHL5ViXxvTNcWhADQBUpS1AkHCr6s yFBk9Jz8NutWq7x4j246hRjZULkXliPhz5diw= Received: by 10.50.170.105 with SMTP id al9mr12801522igc.28.1320420642293; Fri, 04 Nov 2011 08:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Fri, 4 Nov 2011 08:30:12 -0700 (PDT) In-Reply-To: <20111104144300.GF83971@goofy01.vnodelab.local> References: <20111104144300.GF83971@goofy01.vnodelab.local> From: Chris Rees Date: Fri, 4 Nov 2011 15:30:12 +0000 Message-ID: To: Joel Dahl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: doc@freebsd.org Subject: Re: FreeBSD developers / committers list X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 15:30:43 -0000 On 4 November 2011 14:43, Joel Dahl wrote: > On 03-11-2011 20:21, Chris Rees wrote: >> Hey all, >> >> We have a list of developers at [1], and a list of developer alumni at >> [2] -- they seem a little out of date. =A0As of right now (today), there >> are ~90 people on that list who aren't listed in any CVSROOT-*/access >> lists; I'm conscious that most have been Grim Reapered/resigned, and >> the Alumni page hasn't been updated... >> >> Is there a policy on the Alumni page? Is it deliberate that these guys >> have been left in, or just that no-one has updated the page? > > No-one has updated it. I kept it updated for a few years, but not anymore= . > I was hoping someone would grab it. If you want to update it, please go > ahead. > Thanks. Merging 90 odd entries sounds pretty dull by hand, I'll have a go at scripting it and hopefully have a patch ready by later this week (!) Chris