From owner-freebsd-doc@FreeBSD.ORG Sun Oct 23 11:25:11 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 281EF106564A for ; Sun, 23 Oct 2011 11:25:11 +0000 (UTC) (envelope-from jotawski@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B23618FC08 for ; Sun, 23 Oct 2011 11:25:10 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so8918158bkb.13 for ; Sun, 23 Oct 2011 04:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=G4YbRpFXup/NxO+z3iK5o4udyTBNb1TOn7Z/UasQjag=; b=ToyXnGMKfNwijGE+mH7HrsIhog7122OVXd6dpKiSsSYQRb8LasmAzL7HvaRFMnmB3X Csrp4+ShXwTJ05X8zQtxhGCjXauF2JwjfkE/klxAxHbSJkDOpicqeToThgQlAYDsqm/Y TMCWVX+KTwGhrLAmLH71f/B9+ZyoR//WDvHTQ= MIME-Version: 1.0 Received: by 10.205.83.73 with SMTP id af9mr14419309bkc.24.1319367543976; Sun, 23 Oct 2011 03:59:03 -0700 (PDT) Received: by 10.204.114.80 with HTTP; Sun, 23 Oct 2011 03:59:03 -0700 (PDT) Date: Sun, 23 Oct 2011 17:59:03 +0700 Message-ID: From: fire jotawski To: freebsd-doc@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD Thai Documentation Translation Project 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, 23 Oct 2011 11:25:11 -0000 Hi sirs, I am going to translate the documentation as suggestion in http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/translations.html#Q9.8 . I am now have my spare time for translation at least two (2) days in a week. Please accept my intention to do so. with best regards, pirat sriyotha From owner-freebsd-doc@FreeBSD.ORG Mon Oct 24 11:06:07 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 31F6F106566B for ; Mon, 24 Oct 2011 11:06:07 +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 1BB508FC0C for ; Mon, 24 Oct 2011 11:06:07 +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 p9OB67XG024506 for ; Mon, 24 Oct 2011 11:06:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9OB66c6024504 for freebsd-doc@FreeBSD.org; Mon, 24 Oct 2011 11:06:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Oct 2011 11:06:06 GMT Message-Id: <201110241106.p9OB66c6024504@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, 24 Oct 2011 11:06:07 -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/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 198 problems total. From owner-freebsd-doc@FreeBSD.ORG Mon Oct 24 12:27:59 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 B3BD110656E4; Mon, 24 Oct 2011 12:27:59 +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 6FAFE8FC14; Mon, 24 Oct 2011 12:27:56 +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 DEF4846B52; Mon, 24 Oct 2011 08:27:55 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7DFDE8A03E; Mon, 24 Oct 2011 08:27:55 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Mon, 24 Oct 2011 08:27:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20111007141312.GJ26743@acme.spoerlein.net> <201110101301.37276.jhb@freebsd.org> <4EA23FCA.10309@FreeBSD.org> In-Reply-To: <4EA23FCA.10309@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110240827.50750.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 08:27:55 -0400 (EDT) Cc: doc@freebsd.org, doceng@freebsd.org, freebsd-doc@freebsd.org, =?iso-8859-1?q?Sp=F6rlein?= , "Simon L. B. Nielsen" , Ulrich@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: Mon, 24 Oct 2011 12:27:59 -0000 On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: > On 10/10/2011 10:01, John Baldwin wrote: > > On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: > >>>> I'm not really sure where you would fit doc into the current repo... > >>>> head/ etc. is on the top level. > >>> > >>> /doc and /www would be the obvious choices. Ed even jokingly (??) said > >> > >> Well, that seems like a bit of a mess as you mainly have branches at that level... > >> > >>> we should just rename /head to /src ... not sure I concur. > >> > >> Considering we have stable etc. on the same level that seems like a bad thing to do... > > > > I agree with both of these. The layout in svn currently is src-centric and > > only setup to handle src. > > Right now under base/ we have: > > cvs2svn > head > projects > release > releng > stable > svnadmin > user > vendor > vendor-crypto > vendory-sys > ROADMAP.TXT > > Those categories are primarily source-related, but not exclusively. The branches are certainly very src-centric. For example, where would you put doc release tags? If it were the same repository then what you would really like to happen is to make the doc + src trees for a given tag live in the same place. I'm not sure how doable that is. Perhaps we could move 'doc' into the equivalent of 'src/doc' (so head/doc, releng/9.0/doc, release/9.0/doc, etc.). However, that forces docs to be branched (well, you could copy doc from head into each releng tree during each release instead and just delete it from stable branches if you wanted to avoid that, but that's a bit of a PITA). It also means docs can't be "tagged" until a src release branch is created and historically docs have been tagged long before src is ready. I think it would be useful to allow docs to continue to manage their tagging independent of what re@ does for src. > > You would need to move the entire repo down into a > > new "src" directory for it to really work, but we aren't going to do that now. > > I think a separate SVN for doc+www is fine (and not near as much overhead to > > manage as Ulrich fears). > > My primary motivating factor is not the administrative overhead, it's > the fact that elements from the doc repo are used as part of 'make > release.' But it's easy to just check them out from another repository. Even the old make release does a separate checkout operation for docs, and there's no reason that has to use the same exact repository as src. > > Also, I think the discontinuous history idea is a compelling reason to not put > > the doc/www history into source svn. Right now svn changes move forward > > continuously with time (so change N + 1 is "newer" than change N), but > > importing doc+www history as changes that are subsequent to the current top of > > tree would break that. OTOH, renumbering the current tree to put the doc+www > > history in the "right" place is simply not workable now. > > I don't understand any of what you wrote above, but I'd like to. What > I'm thinking is that the cvs->svn converter would simply start with the > next available revision number and that would be the first revision for > the oldest doc commit. When the import was done, the revision numbers > would continue to increase monotonically regardless of whether it was a > doc or src commit. Are you saying that this is not how it would work? I'm saying that humans would find it confusing that revision N would be from today and revision N+1 would be from 1996. -- John Baldwin From owner-freebsd-doc@FreeBSD.ORG Mon Oct 24 12:27: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 B3BD110656E4; Mon, 24 Oct 2011 12:27:59 +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 6FAFE8FC14; Mon, 24 Oct 2011 12:27:56 +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 DEF4846B52; Mon, 24 Oct 2011 08:27:55 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7DFDE8A03E; Mon, 24 Oct 2011 08:27:55 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Mon, 24 Oct 2011 08:27:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20111007141312.GJ26743@acme.spoerlein.net> <201110101301.37276.jhb@freebsd.org> <4EA23FCA.10309@FreeBSD.org> In-Reply-To: <4EA23FCA.10309@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110240827.50750.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 08:27:55 -0400 (EDT) Cc: doc@freebsd.org, doceng@freebsd.org, freebsd-doc@freebsd.org, =?iso-8859-1?q?Sp=F6rlein?= , "Simon L. B. Nielsen" , Ulrich@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: Mon, 24 Oct 2011 12:27:59 -0000 On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: > On 10/10/2011 10:01, John Baldwin wrote: > > On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: > >>>> I'm not really sure where you would fit doc into the current repo... > >>>> head/ etc. is on the top level. > >>> > >>> /doc and /www would be the obvious choices. Ed even jokingly (??) said > >> > >> Well, that seems like a bit of a mess as you mainly have branches at that level... > >> > >>> we should just rename /head to /src ... not sure I concur. > >> > >> Considering we have stable etc. on the same level that seems like a bad thing to do... > > > > I agree with both of these. The layout in svn currently is src-centric and > > only setup to handle src. > > Right now under base/ we have: > > cvs2svn > head > projects > release > releng > stable > svnadmin > user > vendor > vendor-crypto > vendory-sys > ROADMAP.TXT > > Those categories are primarily source-related, but not exclusively. The branches are certainly very src-centric. For example, where would you put doc release tags? If it were the same repository then what you would really like to happen is to make the doc + src trees for a given tag live in the same place. I'm not sure how doable that is. Perhaps we could move 'doc' into the equivalent of 'src/doc' (so head/doc, releng/9.0/doc, release/9.0/doc, etc.). However, that forces docs to be branched (well, you could copy doc from head into each releng tree during each release instead and just delete it from stable branches if you wanted to avoid that, but that's a bit of a PITA). It also means docs can't be "tagged" until a src release branch is created and historically docs have been tagged long before src is ready. I think it would be useful to allow docs to continue to manage their tagging independent of what re@ does for src. > > You would need to move the entire repo down into a > > new "src" directory for it to really work, but we aren't going to do that now. > > I think a separate SVN for doc+www is fine (and not near as much overhead to > > manage as Ulrich fears). > > My primary motivating factor is not the administrative overhead, it's > the fact that elements from the doc repo are used as part of 'make > release.' But it's easy to just check them out from another repository. Even the old make release does a separate checkout operation for docs, and there's no reason that has to use the same exact repository as src. > > Also, I think the discontinuous history idea is a compelling reason to not put > > the doc/www history into source svn. Right now svn changes move forward > > continuously with time (so change N + 1 is "newer" than change N), but > > importing doc+www history as changes that are subsequent to the current top of > > tree would break that. OTOH, renumbering the current tree to put the doc+www > > history in the "right" place is simply not workable now. > > I don't understand any of what you wrote above, but I'd like to. What > I'm thinking is that the cvs->svn converter would simply start with the > next available revision number and that would be the first revision for > the oldest doc commit. When the import was done, the revision numbers > would continue to increase monotonically regardless of whether it was a > doc or src commit. Are you saying that this is not how it would work? I'm saying that humans would find it confusing that revision N would be from today and revision N+1 would be from 1996. -- John Baldwin From owner-freebsd-doc@FreeBSD.ORG Mon Oct 24 15:09:40 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 EAE13106564A for ; Mon, 24 Oct 2011 15:09:40 +0000 (UTC) (envelope-from freesite.organicsales@gmail.com) Received: from mail-pz0-f68.google.com (mail-pz0-f68.google.com [209.85.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id C740E8FC19 for ; Mon, 24 Oct 2011 15:09:39 +0000 (UTC) Received: by pzk33 with SMTP id 33so4638110pzk.7 for ; Mon, 24 Oct 2011 08:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=zEpYz/Cwqp34TfHs+0MVyxhjUZvaxGLYthEgfpYkP90=; b=pQsx9xDNKW5i69Dtl9WpWps1pv+vi/rIVRorvrV2M0SPHv+qx+c7mOYXhpjAfj+gqw Ms3OyNMDNW36Thph7nK1pckHjkLETHbEalQS4l1xICcFCPv02cjpCDWE82bgBrIiGjqn GSU4ph2NkQW4036bNoDdHQoq4W1MzrEd+JVm4= MIME-Version: 1.0 Received: by 10.68.73.232 with SMTP id o8mr22012762pbv.82.1319467945324; Mon, 24 Oct 2011 07:52:25 -0700 (PDT) Received: by 10.142.253.17 with HTTP; Mon, 24 Oct 2011 07:52:25 -0700 (PDT) Date: Mon, 24 Oct 2011 20:22:25 +0530 Message-ID: From: ben mulder To: freebsd-doc@FreeBSD.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Organic SEO - Freebsd.org 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, 24 Oct 2011 15:09:41 -0000 Freebsd.org Team, I thought you might like to know some of the reasons why you are not gettin= g enough Social Media and Organic search engine traffic for Freebsd.org. 1. Social profile is not available in top Social Media websites. 2. Your SEO score is 95%. We can bring it to 100% by implementing on and off-page factors which will fetch better results in major search engines. 3. Your site has 2500 Google back links, this can be improved further. There are many additional improvements that could be made to your website, and if you would like to learn about them, and are curious to know what our working together would involve, then I would be glad to provide you with a detailed analysis in the form of a *WEBSITE AUDIT REPORT *for FREE. To brief you about our company, we are one of the fastest-growing Internet Marketing Company of the world. We give *money back guarantee*. Our clients consistently tell us that their customers find them because the= y are at the top of the Google search rankings. Being at the top left of Google (#1- #3 organic positions) is the best thing you can do for your company's website traffic and online reputation. Sounds interesting? Feel free to email us or alternatively you can provide me with your phone number and the best time to call you. ----------------------------------------------------------------------- Best Regards, *Ben Mulder* SEO Consultanta 315-332-1942 ----------------------------------------------------------------------- PS1: This is onetime email and you may ask us to =93REMOVE=94 you from our mailing list. PS2: I found your site from online advertising but did not click. PS3: We operate 24 x7. I will be happy to send you links to price list, money back guarantee, client rankings, client testimonials, =93How we are different from others?=94, and =93Why should you choose us?=94 on receiving= a response from you. From owner-freebsd-doc@FreeBSD.ORG Mon Oct 24 16:20:03 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 956031065674 for ; Mon, 24 Oct 2011 16:20:03 +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 6BE448FC0A for ; Mon, 24 Oct 2011 16:20:03 +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 p9OGK3MF019805 for ; Mon, 24 Oct 2011 16:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9OGK3TX019804; Mon, 24 Oct 2011 16:20:03 GMT (envelope-from gnats) Date: Mon, 24 Oct 2011 16:20:03 GMT Message-Id: <201110241620.p9OGK3TX019804@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Mohacsi Janos Cc: Subject: Re: docs/111147: hostapd.conf is not documented X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mohacsi Janos List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 16:20:03 -0000 The following reply was made to PR docs/111147; it has been noted by GNATS. From: Mohacsi Janos To: Niclas Zeising Cc: bug-followup@FreeBSD.org, janos.mohacsi@bsd.hu Subject: Re: docs/111147: hostapd.conf is not documented Date: Mon, 24 Oct 2011 18:19:44 +0200 On 10/12/11 16:22, Niclas Zeising wrote: > The example file mentioned in the PR is copied to > /usr/share/examples/hostapd.conf . I guess it is possible to flesh out > the manual page, but that requires someone with a throughout knowledge > of how hostapd.conf works. thanks. From owner-freebsd-doc@FreeBSD.ORG Mon Oct 24 22:05:23 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 101B21065673; Mon, 24 Oct 2011 22:05:23 +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 92E78151561; Mon, 24 Oct 2011 22:05:22 +0000 (UTC) Message-ID: <4EA5E122.8030303@FreeBSD.org> Date: Mon, 24 Oct 2011 15:05:22 -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> <201110101301.37276.jhb@freebsd.org> <4EA23FCA.10309@FreeBSD.org> <201110240827.50750.jhb@freebsd.org> In-Reply-To: <201110240827.50750.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: Mon, 24 Oct 2011 22:05:23 -0000 On 10/24/2011 05:27, John Baldwin wrote: > On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: >> On 10/10/2011 10:01, John Baldwin wrote: >>> On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: >>>>>> I'm not really sure where you would fit doc into the current repo... >>>>>> head/ etc. is on the top level. >>>>> >>>>> /doc and /www would be the obvious choices. Ed even jokingly (??) said >>>> >>>> Well, that seems like a bit of a mess as you mainly have branches at that level... >>>> >>>>> we should just rename /head to /src ... not sure I concur. >>>> >>>> Considering we have stable etc. on the same level that seems like a bad thing to do... >>> >>> I agree with both of these. The layout in svn currently is src-centric and >>> only setup to handle src. >> >> Right now under base/ we have: >> >> cvs2svn >> head >> projects >> release >> releng >> stable >> svnadmin >> user >> vendor >> vendor-crypto >> vendory-sys >> ROADMAP.TXT >> >> Those categories are primarily source-related, but not exclusively. > > The branches are certainly very src-centric. For example, where would you > put doc release tags? What prevents them from being put under release/ ? > If it were the same repository then what you would > really like to happen is to make the doc + src trees for a given tag live > in the same place. I'm not sure how doable that is. Perhaps we could > move 'doc' into the equivalent of 'src/doc' (so head/doc, releng/9.0/doc, > release/9.0/doc, etc.). However, that forces docs to be branched (well, > you could copy doc from head into each releng tree during each release > instead and just delete it from stable branches if you wanted to avoid that, > but that's a bit of a PITA). It also means docs can't be "tagged" until a > src release branch is created and historically docs have been tagged long > before src is ready. I think it would be useful to allow docs to continue > to manage their tagging independent of what re@ does for src. I'm not sure why that wouldn't be able to continue. The impression I'm getting is that you're thinking of worst case scenarios because you don't like the idea of combining repos, rather than being willing to look at obvious solutions and/or lack of actual problems. >>> You would need to move the entire repo down into a >>> new "src" directory for it to really work, but we aren't going to do that now. >>> I think a separate SVN for doc+www is fine (and not near as much overhead to >>> manage as Ulrich fears). >> >> My primary motivating factor is not the administrative overhead, it's >> the fact that elements from the doc repo are used as part of 'make >> release.' > > But it's easy to just check them out from another repository. Even the old > make release does a separate checkout operation for docs, and there's no > reason that has to use the same exact repository as src. The question is not how can we continue to do what we've always done, but how can we do better? >>> Also, I think the discontinuous history idea is a compelling reason to not put >>> the doc/www history into source svn. Right now svn changes move forward >>> continuously with time (so change N + 1 is "newer" than change N), but >>> importing doc+www history as changes that are subsequent to the current top of >>> tree would break that. OTOH, renumbering the current tree to put the doc+www >>> history in the "right" place is simply not workable now. >> >> I don't understand any of what you wrote above, but I'd like to. What >> I'm thinking is that the cvs->svn converter would simply start with the >> next available revision number and that would be the first revision for >> the oldest doc commit. When the import was done, the revision numbers >> would continue to increase monotonically regardless of whether it was a >> doc or src commit. Are you saying that this is not how it would work? > > I'm saying that humans would find it confusing that revision N would be > from today and revision N+1 would be from 1996. I think you're dramatically overestimating how confused people would be by this. Just like the fact that version numbers increase over the whole repo, this is something that people would just get used to over time. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 Mon Oct 24 22:05:23 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 101B21065673; Mon, 24 Oct 2011 22:05:23 +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 92E78151561; Mon, 24 Oct 2011 22:05:22 +0000 (UTC) Message-ID: <4EA5E122.8030303@FreeBSD.org> Date: Mon, 24 Oct 2011 15:05:22 -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> <201110101301.37276.jhb@freebsd.org> <4EA23FCA.10309@FreeBSD.org> <201110240827.50750.jhb@freebsd.org> In-Reply-To: <201110240827.50750.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: Mon, 24 Oct 2011 22:05:23 -0000 On 10/24/2011 05:27, John Baldwin wrote: > On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: >> On 10/10/2011 10:01, John Baldwin wrote: >>> On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: >>>>>> I'm not really sure where you would fit doc into the current repo... >>>>>> head/ etc. is on the top level. >>>>> >>>>> /doc and /www would be the obvious choices. Ed even jokingly (??) said >>>> >>>> Well, that seems like a bit of a mess as you mainly have branches at that level... >>>> >>>>> we should just rename /head to /src ... not sure I concur. >>>> >>>> Considering we have stable etc. on the same level that seems like a bad thing to do... >>> >>> I agree with both of these. The layout in svn currently is src-centric and >>> only setup to handle src. >> >> Right now under base/ we have: >> >> cvs2svn >> head >> projects >> release >> releng >> stable >> svnadmin >> user >> vendor >> vendor-crypto >> vendory-sys >> ROADMAP.TXT >> >> Those categories are primarily source-related, but not exclusively. > > The branches are certainly very src-centric. For example, where would you > put doc release tags? What prevents them from being put under release/ ? > If it were the same repository then what you would > really like to happen is to make the doc + src trees for a given tag live > in the same place. I'm not sure how doable that is. Perhaps we could > move 'doc' into the equivalent of 'src/doc' (so head/doc, releng/9.0/doc, > release/9.0/doc, etc.). However, that forces docs to be branched (well, > you could copy doc from head into each releng tree during each release > instead and just delete it from stable branches if you wanted to avoid that, > but that's a bit of a PITA). It also means docs can't be "tagged" until a > src release branch is created and historically docs have been tagged long > before src is ready. I think it would be useful to allow docs to continue > to manage their tagging independent of what re@ does for src. I'm not sure why that wouldn't be able to continue. The impression I'm getting is that you're thinking of worst case scenarios because you don't like the idea of combining repos, rather than being willing to look at obvious solutions and/or lack of actual problems. >>> You would need to move the entire repo down into a >>> new "src" directory for it to really work, but we aren't going to do that now. >>> I think a separate SVN for doc+www is fine (and not near as much overhead to >>> manage as Ulrich fears). >> >> My primary motivating factor is not the administrative overhead, it's >> the fact that elements from the doc repo are used as part of 'make >> release.' > > But it's easy to just check them out from another repository. Even the old > make release does a separate checkout operation for docs, and there's no > reason that has to use the same exact repository as src. The question is not how can we continue to do what we've always done, but how can we do better? >>> Also, I think the discontinuous history idea is a compelling reason to not put >>> the doc/www history into source svn. Right now svn changes move forward >>> continuously with time (so change N + 1 is "newer" than change N), but >>> importing doc+www history as changes that are subsequent to the current top of >>> tree would break that. OTOH, renumbering the current tree to put the doc+www >>> history in the "right" place is simply not workable now. >> >> I don't understand any of what you wrote above, but I'd like to. What >> I'm thinking is that the cvs->svn converter would simply start with the >> next available revision number and that would be the first revision for >> the oldest doc commit. When the import was done, the revision numbers >> would continue to increase monotonically regardless of whether it was a >> doc or src commit. Are you saying that this is not how it would work? > > I'm saying that humans would find it confusing that revision N would be > from today and revision N+1 would be from 1996. I think you're dramatically overestimating how confused people would be by this. Just like the fact that version numbers increase over the whole repo, this is something that people would just get used to over time. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 Tue Oct 25 18:05:49 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 63544106566B; Tue, 25 Oct 2011 18:05:49 +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 28FBD8FC08; Tue, 25 Oct 2011 18:05:49 +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 B5CDB46B2A; Tue, 25 Oct 2011 14:05:48 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 587158A02F; Tue, 25 Oct 2011 14:05:48 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Tue, 25 Oct 2011 14:05:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111007141312.GJ26743@acme.spoerlein.net> <201110240827.50750.jhb@freebsd.org> <4EA5E122.8030303@FreeBSD.org> In-Reply-To: <4EA5E122.8030303@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110251405.46493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Oct 2011 14:05:48 -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: Tue, 25 Oct 2011 18:05:49 -0000 On Monday, October 24, 2011 6:05:22 pm Doug Barton wrote: > On 10/24/2011 05:27, John Baldwin wrote: > > On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: > >> On 10/10/2011 10:01, John Baldwin wrote: > >>> On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: > >>>>>> I'm not really sure where you would fit doc into the current repo... > >>>>>> head/ etc. is on the top level. > >>>>> > >>>>> /doc and /www would be the obvious choices. Ed even jokingly (??) said > >>>> > >>>> Well, that seems like a bit of a mess as you mainly have branches at that level... > >>>> > >>>>> we should just rename /head to /src ... not sure I concur. > >>>> > >>>> Considering we have stable etc. on the same level that seems like a bad thing to do... > >>> > >>> I agree with both of these. The layout in svn currently is src-centric and > >>> only setup to handle src. > >> > >> Right now under base/ we have: > >> > >> cvs2svn > >> head > >> projects > >> release > >> releng > >> stable > >> svnadmin > >> user > >> vendor > >> vendor-crypto > >> vendory-sys > >> ROADMAP.TXT > >> > >> Those categories are primarily source-related, but not exclusively. > > > > The branches are certainly very src-centric. For example, where would you > > put doc release tags? > > What prevents them from being put under release/ ? So right now what happens is that a release is tagged by re@ doing 'svn cp stable/9 releng/9.0' and eventually 'svn cp releng/9.0 release/9.0'. 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? Note that this would have to happen _after_ the source copy is done as otherwise svn won't let you do the copy for source. This is part of what I was talking about below about forcing doc to tag after src has tagged. Also, if you do this, then doc will show up in a checkout of the release, but not in head, which may or may not be confusing to some folks since the implicit assumption about the checkout of a release being "symmetric" with head and stable branches would be broken. 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). 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. > > If it were the same repository then what you would > > really like to happen is to make the doc + src trees for a given tag live > > in the same place. I'm not sure how doable that is. Perhaps we could > > move 'doc' into the equivalent of 'src/doc' (so head/doc, releng/9.0/doc, > > release/9.0/doc, etc.). However, that forces docs to be branched (well, > > you could copy doc from head into each releng tree during each release > > instead and just delete it from stable branches if you wanted to avoid that, > > but that's a bit of a PITA). It also means docs can't be "tagged" until a > > src release branch is created and historically docs have been tagged long > > before src is ready. I think it would be useful to allow docs to continue > > to manage their tagging independent of what re@ does for src. > > I'm not sure why that wouldn't be able to continue. The impression I'm > getting is that you're thinking of worst case scenarios because you > don't like the idea of combining repos, rather than being willing to > look at obvious solutions and/or lack of actual problems. No, I'm thinking about the actual mechanics of when the svn operations would happen vs how the equivalent actions happen now during a release. > > But it's easy to just check them out from another repository. Even the old > > make release does a separate checkout operation for docs, and there's no > > reason that has to use the same exact repository as src. > > 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. > >>> Also, I think the discontinuous history idea is a compelling reason to not put > >>> the doc/www history into source svn. Right now svn changes move forward > >>> continuously with time (so change N + 1 is "newer" than change N), but > >>> importing doc+www history as changes that are subsequent to the current top of > >>> tree would break that. OTOH, renumbering the current tree to put the doc+www > >>> history in the "right" place is simply not workable now. > >> > >> I don't understand any of what you wrote above, but I'd like to. What > >> I'm thinking is that the cvs->svn converter would simply start with the > >> next available revision number and that would be the first revision for > >> the oldest doc commit. When the import was done, the revision numbers > >> would continue to increase monotonically regardless of whether it was a > >> doc or src commit. Are you saying that this is not how it would work? > > > > I'm saying that humans would find it confusing that revision N would be > > from today and revision N+1 would be from 1996. > > I think you're dramatically overestimating how confused people would be > by this. Just like the fact that version numbers increase over the whole > repo, this is something that people would just get used to over time. Maybe so. Still, I depend on this implicit stuff a good bit when dealing with historical info in the form of commit logs via 'annotate', etc. (which I actually do a lot in src). Since the doc and src bits wouldn't actually overlap, perhaps that would not matter for someone in the future who is looking at past history since the streams should not cross. 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. OTOH, if that is a desired feature there isn't really any way around that at this point. -- John Baldwin From owner-freebsd-doc@FreeBSD.ORG Tue Oct 25 18:05:49 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 63544106566B; Tue, 25 Oct 2011 18:05:49 +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 28FBD8FC08; Tue, 25 Oct 2011 18:05:49 +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 B5CDB46B2A; Tue, 25 Oct 2011 14:05:48 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 587158A02F; Tue, 25 Oct 2011 14:05:48 -0400 (EDT) From: John Baldwin To: Doug Barton Date: Tue, 25 Oct 2011 14:05:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <20111007141312.GJ26743@acme.spoerlein.net> <201110240827.50750.jhb@freebsd.org> <4EA5E122.8030303@FreeBSD.org> In-Reply-To: <4EA5E122.8030303@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110251405.46493.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Oct 2011 14:05:48 -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: Tue, 25 Oct 2011 18:05:49 -0000 On Monday, October 24, 2011 6:05:22 pm Doug Barton wrote: > On 10/24/2011 05:27, John Baldwin wrote: > > On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: > >> On 10/10/2011 10:01, John Baldwin wrote: > >>> On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: > >>>>>> I'm not really sure where you would fit doc into the current repo... > >>>>>> head/ etc. is on the top level. > >>>>> > >>>>> /doc and /www would be the obvious choices. Ed even jokingly (??) said > >>>> > >>>> Well, that seems like a bit of a mess as you mainly have branches at that level... > >>>> > >>>>> we should just rename /head to /src ... not sure I concur. > >>>> > >>>> Considering we have stable etc. on the same level that seems like a bad thing to do... > >>> > >>> I agree with both of these. The layout in svn currently is src-centric and > >>> only setup to handle src. > >> > >> Right now under base/ we have: > >> > >> cvs2svn > >> head > >> projects > >> release > >> releng > >> stable > >> svnadmin > >> user > >> vendor > >> vendor-crypto > >> vendory-sys > >> ROADMAP.TXT > >> > >> Those categories are primarily source-related, but not exclusively. > > > > The branches are certainly very src-centric. For example, where would you > > put doc release tags? > > What prevents them from being put under release/ ? So right now what happens is that a release is tagged by re@ doing 'svn cp stable/9 releng/9.0' and eventually 'svn cp releng/9.0 release/9.0'. 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? Note that this would have to happen _after_ the source copy is done as otherwise svn won't let you do the copy for source. This is part of what I was talking about below about forcing doc to tag after src has tagged. Also, if you do this, then doc will show up in a checkout of the release, but not in head, which may or may not be confusing to some folks since the implicit assumption about the checkout of a release being "symmetric" with head and stable branches would be broken. 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). 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. > > If it were the same repository then what you would > > really like to happen is to make the doc + src trees for a given tag live > > in the same place. I'm not sure how doable that is. Perhaps we could > > move 'doc' into the equivalent of 'src/doc' (so head/doc, releng/9.0/doc, > > release/9.0/doc, etc.). However, that forces docs to be branched (well, > > you could copy doc from head into each releng tree during each release > > instead and just delete it from stable branches if you wanted to avoid that, > > but that's a bit of a PITA). It also means docs can't be "tagged" until a > > src release branch is created and historically docs have been tagged long > > before src is ready. I think it would be useful to allow docs to continue > > to manage their tagging independent of what re@ does for src. > > I'm not sure why that wouldn't be able to continue. The impression I'm > getting is that you're thinking of worst case scenarios because you > don't like the idea of combining repos, rather than being willing to > look at obvious solutions and/or lack of actual problems. No, I'm thinking about the actual mechanics of when the svn operations would happen vs how the equivalent actions happen now during a release. > > But it's easy to just check them out from another repository. Even the old > > make release does a separate checkout operation for docs, and there's no > > reason that has to use the same exact repository as src. > > 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. > >>> Also, I think the discontinuous history idea is a compelling reason to not put > >>> the doc/www history into source svn. Right now svn changes move forward > >>> continuously with time (so change N + 1 is "newer" than change N), but > >>> importing doc+www history as changes that are subsequent to the current top of > >>> tree would break that. OTOH, renumbering the current tree to put the doc+www > >>> history in the "right" place is simply not workable now. > >> > >> I don't understand any of what you wrote above, but I'd like to. What > >> I'm thinking is that the cvs->svn converter would simply start with the > >> next available revision number and that would be the first revision for > >> the oldest doc commit. When the import was done, the revision numbers > >> would continue to increase monotonically regardless of whether it was a > >> doc or src commit. Are you saying that this is not how it would work? > > > > I'm saying that humans would find it confusing that revision N would be > > from today and revision N+1 would be from 1996. > > I think you're dramatically overestimating how confused people would be > by this. Just like the fact that version numbers increase over the whole > repo, this is something that people would just get used to over time. Maybe so. Still, I depend on this implicit stuff a good bit when dealing with historical info in the form of commit logs via 'annotate', etc. (which I actually do a lot in src). Since the doc and src bits wouldn't actually overlap, perhaps that would not matter for someone in the future who is looking at past history since the streams should not cross. 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. OTOH, if that is a desired feature there isn't really any way around that at this point. -- John Baldwin From owner-freebsd-doc@FreeBSD.ORG Fri Oct 28 15:48: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 430B3106564A for ; Fri, 28 Oct 2011 15:48:21 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0965B8FC0C for ; Fri, 28 Oct 2011 15:48:20 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-091-089-161-008.hsi2.kabel-badenwuerttemberg.de [91.89.161.8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id A243C7E888 for ; Fri, 28 Oct 2011 17:30:16 +0200 (CEST) Message-ID: <4EAACA87.9060806@bsdforen.de> Date: Fri, 28 Oct 2011 17:30:15 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111006 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-doc@freebsd.org X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit Subject: Attaching permanent links to mails 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, 28 Oct 2011 15:48:21 -0000 I hope this is the right place to suggest this, I choose this list, because mail is filed under docs.freebsd.org/mail/. I find myself referencing mails from the freebsd mailing lists quite frequently, e.g. referencing a related thread/mail. To do this, I check the date of the e-mail and manually dig the permanent link out of the archives. What I'd really love to see if the mailing list software automatically added a signature like this to each mail it distributes: -- Archived under: http://docs.freebsd.org/cgi/mid.cgi?4EA81B90.60501 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-doc@FreeBSD.ORG Fri Oct 28 16:30:14 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 8E008106566C for ; Fri, 28 Oct 2011 16:30:14 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 557348FC13 for ; Fri, 28 Oct 2011 16:30:14 +0000 (UTC) Received: (qmail 79709 invoked by uid 0); 28 Oct 2011 12:30:13 -0400 Received: from unknown (HELO schism.local) (gjb@75.146.225.65) by 0 with SMTP; 28 Oct 2011 12:30:13 -0400 Message-ID: <4EAAD892.4030306@FreeBSD.org> Date: Fri, 28 Oct 2011 12:30:10 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Dominic Fandrey References: <4EAACA87.9060806@bsdforen.de> In-Reply-To: <4EAACA87.9060806@bsdforen.de> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4C10F2DB8DAA7441B90D65B2" Cc: freebsd-doc@freebsd.org, postmaster@freebsd.org Subject: Re: Attaching permanent links to mails 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, 28 Oct 2011 16:30:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4C10F2DB8DAA7441B90D65B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, On 10/28/11 11:30 AM, Dominic Fandrey wrote: > I hope this is the right place to suggest this, I choose this list, > because mail is filed under docs.freebsd.org/mail/. >=20 > I find myself referencing mails from the freebsd mailing lists quite > frequently, e.g. referencing a related thread/mail. >=20 > To do this, I check the date of the e-mail and manually dig the permane= nt > link out of the archives. >=20 > What I'd really love to see if the mailing list software automatically > added a signature like this to each mail it distributes: > -- > Archived under: http://docs.freebsd.org/cgi/mid.cgi?4EA81B90.60501 >=20 This request might be best made to postmaster@ (CC'd). Regards, Glen --=20 Glen Barber | gjb@FreeBSD.org FreeBSD Documentation Project --------------enig4C10F2DB8DAA7441B90D65B2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBCAAGBQJOqtiWAAoJEFJPDDeguUajjaoIAJX/OufPZLApLpShAF4VgKlF zNu9p0r52ddoVeRrybw8f9vjdzWXaoD4diO4Zb9dJMaQlO+cm4pGZB1MsKc5QLq3 tti3VHT2BmQk3sJmTC2ZIx5ldbplz4gd7yfcrzPZ3JtY8MBOrVdjNbI2gVfef8Kw WvUS/rI4dp2ETETkuDEjCZDckJsVFm3VOwCQmD2ukdI1BW9uXtE5AllDNOF3X0WD d1ZaLWfEDTgwAD+TsOChygauS2s7yzct4S24iFgHUQ96dL81cQoEjYEfQiGDwmFT p/WF/PMNt7Ay4YHpC1He3C4dW12ug8psw201W1BtRs4IviCIcLSNZMSLxvB7soo= =2EaE -----END PGP SIGNATURE----- --------------enig4C10F2DB8DAA7441B90D65B2-- From owner-freebsd-doc@FreeBSD.ORG Sat Oct 29 07:52:12 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 6536B106566B; Sat, 29 Oct 2011 07:52:12 +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 1154C15724D; Sat, 29 Oct 2011 07:52:12 +0000 (UTC) Message-ID: <4EABB0AB.9070808@FreeBSD.org> Date: Sat, 29 Oct 2011 00:52:11 -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> <201110240827.50750.jhb@freebsd.org> <4EA5E122.8030303@FreeBSD.org> <201110251405.46493.jhb@freebsd.org> In-Reply-To: <201110251405.46493.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: Sat, 29 Oct 2011 07:52:12 -0000 On 10/25/2011 11:05, John Baldwin wrote: > On Monday, October 24, 2011 6:05:22 pm Doug Barton wrote: >> On 10/24/2011 05:27, John Baldwin wrote: >>> On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: >>>> On 10/10/2011 10:01, John Baldwin wrote: >>>>> On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: >>>>>>>> I'm not really sure where you would fit doc into the current repo... >>>>>>>> head/ etc. is on the top level. >>>>>>> >>>>>>> /doc and /www would be the obvious choices. Ed even jokingly (??) said >>>>>> >>>>>> Well, that seems like a bit of a mess as you mainly have branches at that level... >>>>>> >>>>>>> we should just rename /head to /src ... not sure I concur. >>>>>> >>>>>> Considering we have stable etc. on the same level that seems like a bad thing to do... >>>>> >>>>> I agree with both of these. The layout in svn currently is src-centric and >>>>> only setup to handle src. >>>> >>>> Right now under base/ we have: >>>> >>>> cvs2svn >>>> head >>>> projects >>>> release >>>> releng >>>> stable >>>> svnadmin >>>> user >>>> vendor >>>> vendor-crypto >>>> vendory-sys >>>> ROADMAP.TXT >>>> >>>> Those categories are primarily source-related, but not exclusively. >>> >>> The branches are certainly very src-centric. For example, where would you >>> put doc release tags? >> >> What prevents them from being put under release/ ? > > So right now what happens is that a release is tagged by re@ doing > 'svn cp stable/9 releng/9.0' and eventually 'svn cp releng/9.0 release/9.0'. > > 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 I don't see any value in duplicating the src process line by line, only the bits that are relevant. > 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. > 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. >> 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. >>>>> Also, I think the discontinuous history idea is a compelling reason to not put >>>>> the doc/www history into source svn. Right now svn changes move forward >>>>> continuously with time (so change N + 1 is "newer" than change N), but >>>>> importing doc+www history as changes that are subsequent to the current top of >>>>> tree would break that. OTOH, renumbering the current tree to put the doc+www >>>>> history in the "right" place is simply not workable now. >>>> >>>> I don't understand any of what you wrote above, but I'd like to. What >>>> I'm thinking is that the cvs->svn converter would simply start with the >>>> next available revision number and that would be the first revision for >>>> the oldest doc commit. When the import was done, the revision numbers >>>> would continue to increase monotonically regardless of whether it was a >>>> doc or src commit. Are you saying that this is not how it would work? >>> >>> I'm saying that humans would find it confusing that revision N would be >>> from today and revision N+1 would be from 1996. >> >> I think you're dramatically overestimating how confused people would be >> by this. Just like the fact that version numbers increase over the whole >> repo, this is something that people would just get used to over time. > > Maybe so. Still, I depend on this implicit stuff a good bit when dealing > with historical info in the form of commit logs via 'annotate', etc. > (which I actually do a lot in src). Since the doc and src bits wouldn't > actually overlap, perhaps that would not matter for someone in the future > who is looking at past history since the streams should not cross. Exactly. We've learned to cope with subsequent revisions to a given file being 10's of thousands of revision numbers apart, the numbers are just numbers. As long as they increase monotonically the numbers themselves are not relevant. They are merely conveniently-unique symbolic representations of the given change set. Git actually sort of gets this right, it's just that their unfortunate choice of using a checksum doesn't allow for the use of a VCS $Id. > 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. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 Sat Oct 29 07:52:12 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 6536B106566B; Sat, 29 Oct 2011 07:52:12 +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 1154C15724D; Sat, 29 Oct 2011 07:52:12 +0000 (UTC) Message-ID: <4EABB0AB.9070808@FreeBSD.org> Date: Sat, 29 Oct 2011 00:52:11 -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> <201110240827.50750.jhb@freebsd.org> <4EA5E122.8030303@FreeBSD.org> <201110251405.46493.jhb@freebsd.org> In-Reply-To: <201110251405.46493.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: Sat, 29 Oct 2011 07:52:12 -0000 On 10/25/2011 11:05, John Baldwin wrote: > On Monday, October 24, 2011 6:05:22 pm Doug Barton wrote: >> On 10/24/2011 05:27, John Baldwin wrote: >>> On Saturday, October 22, 2011 12:00:10 am Doug Barton wrote: >>>> On 10/10/2011 10:01, John Baldwin wrote: >>>>> On Saturday, October 08, 2011 12:16:59 pm Simon L. B. Nielsen wrote: >>>>>>>> I'm not really sure where you would fit doc into the current repo... >>>>>>>> head/ etc. is on the top level. >>>>>>> >>>>>>> /doc and /www would be the obvious choices. Ed even jokingly (??) said >>>>>> >>>>>> Well, that seems like a bit of a mess as you mainly have branches at that level... >>>>>> >>>>>>> we should just rename /head to /src ... not sure I concur. >>>>>> >>>>>> Considering we have stable etc. on the same level that seems like a bad thing to do... >>>>> >>>>> I agree with both of these. The layout in svn currently is src-centric and >>>>> only setup to handle src. >>>> >>>> Right now under base/ we have: >>>> >>>> cvs2svn >>>> head >>>> projects >>>> release >>>> releng >>>> stable >>>> svnadmin >>>> user >>>> vendor >>>> vendor-crypto >>>> vendory-sys >>>> ROADMAP.TXT >>>> >>>> Those categories are primarily source-related, but not exclusively. >>> >>> The branches are certainly very src-centric. For example, where would you >>> put doc release tags? >> >> What prevents them from being put under release/ ? > > So right now what happens is that a release is tagged by re@ doing > 'svn cp stable/9 releng/9.0' and eventually 'svn cp releng/9.0 release/9.0'. > > 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 I don't see any value in duplicating the src process line by line, only the bits that are relevant. > 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. > 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. >> 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. >>>>> Also, I think the discontinuous history idea is a compelling reason to not put >>>>> the doc/www history into source svn. Right now svn changes move forward >>>>> continuously with time (so change N + 1 is "newer" than change N), but >>>>> importing doc+www history as changes that are subsequent to the current top of >>>>> tree would break that. OTOH, renumbering the current tree to put the doc+www >>>>> history in the "right" place is simply not workable now. >>>> >>>> I don't understand any of what you wrote above, but I'd like to. What >>>> I'm thinking is that the cvs->svn converter would simply start with the >>>> next available revision number and that would be the first revision for >>>> the oldest doc commit. When the import was done, the revision numbers >>>> would continue to increase monotonically regardless of whether it was a >>>> doc or src commit. Are you saying that this is not how it would work? >>> >>> I'm saying that humans would find it confusing that revision N would be >>> from today and revision N+1 would be from 1996. >> >> I think you're dramatically overestimating how confused people would be >> by this. Just like the fact that version numbers increase over the whole >> repo, this is something that people would just get used to over time. > > Maybe so. Still, I depend on this implicit stuff a good bit when dealing > with historical info in the form of commit logs via 'annotate', etc. > (which I actually do a lot in src). Since the doc and src bits wouldn't > actually overlap, perhaps that would not matter for someone in the future > who is looking at past history since the streams should not cross. Exactly. We've learned to cope with subsequent revisions to a given file being 10's of thousands of revision numbers apart, the numbers are just numbers. As long as they increase monotonically the numbers themselves are not relevant. They are merely conveniently-unique symbolic representations of the given change set. Git actually sort of gets this right, it's just that their unfortunate choice of using a checksum doesn't allow for the use of a VCS $Id. > 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. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go 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 Sat Oct 29 16:50:09 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 E9875106566B for ; Sat, 29 Oct 2011 16:50:08 +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 C6FB98FC15 for ; Sat, 29 Oct 2011 16:50:08 +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 p9TGo1ua025124 for ; Sat, 29 Oct 2011 16:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9TGo1dj025123; Sat, 29 Oct 2011 16:50:01 GMT (envelope-from gnats) Resent-Date: Sat, 29 Oct 2011 16:50:01 GMT Resent-Message-Id: <201110291650.p9TGo1dj025123@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, "r. clayton" Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DFE81065674 for ; Sat, 29 Oct 2011 16:41:51 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF108FC08 for ; Sat, 29 Oct 2011 16:41:51 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p9TGfows093733 for ; Sat, 29 Oct 2011 16:41:50 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p9TGfoOg093732; Sat, 29 Oct 2011 16:41:50 GMT (envelope-from nobody) Message-Id: <201110291641.p9TGfoOg093732@red.freebsd.org> Date: Sat, 29 Oct 2011 16:41:50 GMT From: "r. clayton" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: 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: Sat, 29 Oct 2011 16:50:09 -0000 >Number: 162154 >Category: docs >Synopsis: Handbook section 6.4.2 misordering. >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: Sat Oct 29 16:50:01 UTC 2011 >Closed-Date: >Last-Modified: >Originator: r. clayton >Release: 8.2 >Organization: monmouth u. >Environment: FreeBSD WestRunton 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: The two paragraphs As of version 7.3, Xorg can often work without any configuration file by simply typing at prompt: % startx Starting with version 7.4, Xorg can use HAL to autodetect keyboards and mice. The sysutils/hal and devel/dbus ports are installed as dependencies of x11/xorg, but must be enabled by the following entries in the /etc/rc.conf file: hald_enable="YES" dbus_enable="YES" These services should be started (either manually or by rebooting) before further Xorg configuration is attempted. in section 6.4.2 of http://www.freebsd.org/doc/handbook/x-config.html are in reverse order. My experience has been running startx without enabling hald and dbus leaves me without a mouse or keyboard. >How-To-Repeat: Install xorg from ports, stop reading section 6.4 after the startx part, run startx. >Fix: It might be more accurate and helpful to flip the two paragraphs, something like Starting with version 7.4, Xorg can use HAL to autodetect keyboards and mice. The sysutils/hal and devel/dbus ports are installed as dependencies of x11/xorg, but must be enabled by the following entries in the /etc/rc.conf file: hald_enable="YES" dbus_enable="YES" These services should be started (either manually or by rebooting) before further Xorg configuration is attempted. As of version 7.3, Xorg can often work without any configuration file by simply typing at prompt: % startx with suitable adjustments to the sentence starting "These services..." to indicate that not only should these services be enabled before configuration, but before using X11 at all. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-doc@FreeBSD.ORG Sat Oct 29 18:10:09 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 422F3106566C for ; Sat, 29 Oct 2011 18:10:09 +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 27CD88FC0A for ; Sat, 29 Oct 2011 18:10: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 p9TIA8P4097074 for ; Sat, 29 Oct 2011 18:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9TIA8A2097073; Sat, 29 Oct 2011 18:10:08 GMT (envelope-from gnats) Date: Sat, 29 Oct 2011 18:10:08 GMT Message-Id: <201110291810.p9TIA8A2097073@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Manolis Kiagias Cc: Subject: Re: docs/162154: Handbook section 6.4.2 misordering. X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manolis Kiagias List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 18:10:09 -0000 The following reply was made to PR docs/162154; it has been noted by GNATS. From: Manolis Kiagias To: "r. clayton" Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: docs/162154: Handbook section 6.4.2 misordering. Date: Sat, 29 Oct 2011 20:36:18 +0300 On 29/10/2011 7:41 μμ, r. clayton wrote: > > Description: > The two paragraphs > > As of version 7.3, Xorg can often work without any configuration file by > simply typing at prompt: > > % startx > > Starting with version 7.4, Xorg can use HAL to autodetect keyboards and > mice. The sysutils/hal and devel/dbus ports are installed as dependencies of > x11/xorg, but must be enabled by the following entries in the /etc/rc.conf > file: > > hald_enable="YES" > dbus_enable="YES" > > These services should be started (either manually or by rebooting) before > further Xorg configuration is attempted. > > in section 6.4.2 of > > http://www.freebsd.org/doc/handbook/x-config.html > > are in reverse order. My experience has been running startx without enabling hald and dbus leaves me without a mouse or keyboard. >> How-To-Repeat: > Install xorg from ports, stop reading section 6.4 after the startx part, run startx. Heh, not a good idea to stop reading at the middle of the section :) But I totally agree with you about the ordering of the paragraphs. >> Fix: > It might be more accurate and helpful to flip the two paragraphs, something like > > Starting with version 7.4, Xorg can use HAL to autodetect keyboards and > mice. The sysutils/hal and devel/dbus ports are installed as dependencies of > x11/xorg, but must be enabled by the following entries in the /etc/rc.conf > file: > > hald_enable="YES" > dbus_enable="YES" > > These services should be started (either manually or by rebooting) before > further Xorg configuration is attempted. > > As of version 7.3, Xorg can often work without any configuration file by > simply typing at prompt: > > % startx > > with suitable adjustments to the sentence starting "These services..." to > indicate that not only should these services be enabled before configuration, > but before using X11 at all. > In fact, I think we can completely remove the version information at this point. We've had 7.5 in the ports for some time now, I doubt anyone would install 7.2 now - the reference only serves historical purposes. I would suggest something like the following: "Xorg uses HAL to autodetect keyboards and mice. The sysutils/hal and devel/dbus ports are installed as dependencies of x11/xorg, but must be enabled by the following entries in the /etc/rc.conf file: hald_enable="YES" dbus_enable="YES" These services should be started (either manually or by rebooting) before further Xorg configuration or use is attempted. Xorg can often work without any further configuration steps, by simply typing at prompt: % startx The automatic configuration may fail to work with some hardware, or may not set things up quite as desired. In these cases, manual configuration will be necessary...." From owner-freebsd-doc@FreeBSD.ORG Sat Oct 29 18:12:16 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 B01F6106564A; Sat, 29 Oct 2011 18:12:16 +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 501048FC14; Sat, 29 Oct 2011 18:12:16 +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 p9TICGp6005240; Sat, 29 Oct 2011 18:12:16 GMT (envelope-from manolis@freefall.freebsd.org) Received: (from manolis@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9TICG9m005236; Sat, 29 Oct 2011 18:12:16 GMT (envelope-from manolis) Date: Sat, 29 Oct 2011 18:12:16 GMT Message-Id: <201110291812.p9TICG9m005236@freefall.freebsd.org> To: manolis@FreeBSD.org, freebsd-doc@FreeBSD.org, manolis@FreeBSD.org From: manolis@FreeBSD.org Cc: 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: Sat, 29 Oct 2011 18:12:16 -0000 Synopsis: [handbook] section 6.4.2 misordering. Responsible-Changed-From-To: freebsd-doc->manolis Responsible-Changed-By: manolis Responsible-Changed-When: Sat Oct 29 18:11:44 UTC 2011 Responsible-Changed-Why: I'll handle this one http://www.freebsd.org/cgi/query-pr.cgi?pr=162154 From owner-freebsd-doc@FreeBSD.ORG Sat Oct 29 18:33: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 BD9551065670; Sat, 29 Oct 2011 18:33:43 +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 1EAE68FC14; Sat, 29 Oct 2011 18:33:42 +0000 (UTC) Received: by faar19 with SMTP id r19so6433953faa.13 for ; Sat, 29 Oct 2011 11:33:42 -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 :content-type:content-transfer-encoding; bh=bLVzQjVt9JXIrY2SzQXUOOht8tZa+isdgjXoAnDS6G0=; b=YdbJWtmBi0JQNTj2wpHlsEmDtTFLthB8BykW96uin0oqJMqdeyxsrabo9DP2hZ7sVk asFIh6VEQp5uDhNKcx64CC53LzmWkIxZt0s8H2nqODnFpC2MyffJDvufMZDktYKYxkpi gYL9bB2/K1/smFrBpd2YKknK9oFRbIloD/vVU= Received: by 10.223.36.193 with SMTP id u1mr15286351fad.27.1319911792221; Sat, 29 Oct 2011 11:09:52 -0700 (PDT) Received: from [192.168.0.150] (athedsl-4364788.home.otenet.gr. [79.130.9.228]) by mx.google.com with ESMTPS id y8sm25737414faj.10.2011.10.29.11.09.50 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Oct 2011 11:09:51 -0700 (PDT) Message-ID: <4EAC4171.1010702@gmail.com> Date: Sat, 29 Oct 2011 21:09:53 +0300 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: bug-followup@FreeBSD.org, rclayton@monmouth.edu Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: "doc@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: Sat, 29 Oct 2011 18:33:43 -0000 Here is a complete patch, also with version information removed: http://www.freebsdgr.org/all/en_US.ISO8859-1/books/handbook/x11/x11.patch And a test build here: http://www.freebsdgr.org/all/en_US.ISO8859-1/books/handbook/x-config.html This clears up the chapter a bit, I doubt we need to reference 7.3 and earlier versions specifically anymore. Any objections? From owner-freebsd-doc@FreeBSD.ORG Sat Oct 29 20:53:16 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 86608106566B for ; Sat, 29 Oct 2011 20:53:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with SMTP id 335F98FC0C for ; Sat, 29 Oct 2011 20:53:15 +0000 (UTC) Received: (qmail 23168 invoked by uid 0); 29 Oct 2011 16:53:15 -0400 Received: from unknown (HELO schism.local) (gjb@76.124.49.145) by 0 with SMTP; 29 Oct 2011 16:53:15 -0400 Message-ID: <4EAC67B6.3020900@FreeBSD.org> Date: Sat, 29 Oct 2011 16:53:10 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Manolis Kiagias References: <4EAC4171.1010702@gmail.com> In-Reply-To: <4EAC4171.1010702@gmail.com> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig4A6B6EFAC80509008463CDDE" Cc: rclayton@monmouth.edu, "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: Sat, 29 Oct 2011 20:53:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A6B6EFAC80509008463CDDE Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Hi Manolis, On 10/29/11 2:09 PM, Manolis Kiagias wrote: > Here is a complete patch, also with version information removed: >=20 > http://www.freebsdgr.org/all/en_US.ISO8859-1/books/handbook/x11/x11.pat= ch >=20 > And a test build here: >=20 > http://www.freebsdgr.org/all/en_US.ISO8859-1/books/handbook/x-config.ht= ml >=20 > This clears up the chapter a bit, I doubt we need to reference 7.3 and > earlier versions specifically anymore. Any objections? I think it looks good. I say go for it. :-) --=20 Glen Barber | gjb@FreeBSD.org FreeBSD Documentation Project --------------enig4A6B6EFAC80509008463CDDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQEcBAEBCAAGBQJOrGe6AAoJEFJPDDeguUajHYkIALuKZh2aMjjOLbYgHOqClrk8 YS0S6AavaavULSEfJ8uk22CsjdqMfjHkpGf70Siv+xhDVHcQaKLBu7Kd8DPWYnOj ijCFiIUfCIi0RjIvhSrFtDJ1gSJlvjG3n0T+fJOhKA+7ZcMuJV2+pueOO1d0C1BX lsFiBj+qh5evrbIGqW+Q2n5un0wUgif1orRcqEb5UnpuQzEhRePpR9V5QdFFeSUr gxvRKwIT/Torpyn5GM252+d9QOUZR2BvAh+SKlJk5dShj8MeKo0BWciDvp52j+Rg C5kDKpLr2AoBmXYn7b/iLzXnRkE8+I9VMqK126Lt9rSGeAhf3kf7Prh9it/LoJA= =t/LE -----END PGP SIGNATURE----- --------------enig4A6B6EFAC80509008463CDDE--