Date: Sun, 13 Oct 2013 15:39:14 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Nathan Whitehorn <nwhitehorn@anacreon.physics.wisc.edu> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, Nathan Whitehorn <nwhitehorn@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Devin Teske <dteske@FreeBSD.org> Subject: Re: svn commit: r256343 - in head/usr.sbin/bsdinstall: . scripts Message-ID: <13CA24D6AB415D428143D44749F57D720FC60628@LTCFISWMSGMB21.FNFIS.com> In-Reply-To: <alpine.BSF.2.00.1310130232370.33798@anacreon.physics.wisc.edu> References: <201310112041.r9BKfZeT002056@svn.freebsd.org> <5258F9B3.7030101@freebsd.org> <13CA24D6AB415D428143D44749F57D720FC5BB95@LTCFISWMSGMB21.FNFIS.com> <alpine.BSF.2.00.1310130232370.33798@anacreon.physics.wisc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 13, 2013, at 12:41 AM, Nathan Whitehorn wrote: >=20 >=20 > On Sat, 12 Oct 2013, Teske, Devin wrote: >=20 >>=20 >> On Oct 12, 2013, at 12:26 AM, Nathan Whitehorn wrote: >>=20 >>> On 10/11/13 22:41, Devin Teske wrote: >>>> Author: dteske >>>> Date: Fri Oct 11 20:41:35 2013 >>>> New Revision: 256343 >>>> URL: https://urldefense.proofpoint.com/v1/url?u=3Dhttp://svnweb.freebs= d.org/changeset/base/256343&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DMrj= s6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0A&m=3DLDzuPpXPP4D5BzfISZjw%2BXitYn4aKVzfXzcr= mMNFo2U%3D%0A&s=3D3d0963d9c497f7bad0918888032ca62844580612dc48ab3a8a6768fe6= 40c365b >>>>=20 >>>> Log: >>>> Add zfsboot module as an option for automatic configuration. Default is >>>> to run interactively but it can be scripted too (optinally completely >>>> non-interactive). Currently supports GELI and all ZFS vdev types. Also >>>> performs validation on selections/settings providing error messages if >>>> necessary, explaining (in plain language) what the issue is. Currently >>>> the auto partitioning of naked disks only supports GPT and MBR (VTOC8 >>>> pending for sparc64), so is only available for i386/amd64 install. >>>>=20 >>>> Submitted by: Allan Jude <freebsd@allanjude.com>, myself >>>> Reviewed by: Allan Jude <freebsd@allanjude.com> >>>> Approved by: re (glebius) >>>=20 >>> Hi Devin -- >>>=20 >>> As was discussed on the mailing list, this patch still has some issues >>> that need to be resolved, >>=20 >> Can you kindly provide links? I'm crawling through the mailing lists and >> not finding anything for the October, (current, stable, sysinstall, ... = ?? others?) >>=20 >> Do I need to be looking back in September? I wouldn't think so, because = that >> bit wasn't even in our development tree until October 1st: >=20 > This was discussion on freebsd-current from yesterday and the day before. >=20 Links or it didn't happen. HINT: I just (for the the third time on this topic) crawled the following: http://lists.freebsd.org/pipermail/freebsd-current/2013-October/thread.html Please help me find what you're talking about. >> https://urldefense.proofpoint.com/v1/url?u=3Dhttp://druidbsd.cvs.sf.net/= viewvc/druidbsd/bsdinstall_zfs/usr.sbin%253A%253Absdconfig%253A%253Ashare%2= 53A%253Adevice.subr.patch?revision%3D1.1%26view%3Dmarkup&k=3D%2FbkpAUdJWZui= TILCq%2FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%= 0A&m=3Daas9lyFMptmk4eQ3C74XXVkRHbiN19EOClxMMjoCuhE%3D%0A&s=3D9d21b812e49d92= 1455e998bde7c538318c3bfcc8759c1d0b61eede553b203865 >>=20 >> So there couldn't have been any discussion on it before then. So I'm jus= t not >> able to find the mailing lists where all the action is that they're disc= ussing it. >> Would be nice to find where the action is, so I could participate. >>=20 >>=20 >>> for example the use of camcontrol >>> unconditionally even when the disks may not be CAM >>=20 >> Allan Adds: >> 9.2 should have all disks listed in camcontrol, so it shouldn't be an is= sue >=20 > No it shouldn't. Not all disks are interfaced to CAM. MFI comes to mind, = nvme, VM block devices, SD cards. There are many other examples. OK... duly noted. Much thanks for dispelling that myth. > Just because you don't have them does not justify a phenomenological appr= oach here. >=20 Need I remind you... we don't *list* the disks from camcontrol... we just u= se it as a perfunctory value-add by stealing disk descriptions from it if/when it is describing a = disk. I would hardly call that phenomenological (rather, more of a multi-pass car= tesian ontological approach). >> And: >> I think the only systems without cam based disks are old 8.x - we're onl= y targeting 10 anyway. >=20 > Not true at all. >=20 Thanks. >> I tend to agree with those statements. >>=20 >>=20 >>> and destruction of >>> existing sub-partitioning for MBR disks. >>=20 >> I think we both (Allan and I) actually responded directly to you on this= one. >>=20 >> We have code that handles that. It's in there. >=20 > To me, yes, but I was wrong in my initial comment as pointed out by some = others. In particular, you need to run gpart -F destroy recursively on the = disk instead of just on the root node. There were several other issues and = bugs mentioned in people's cursory review of the patch. Where? by whom? and when? We've already established that it wasn't in the mailing lists (or at least = not in -current as you claim). > I never dreamed you would then just commit it. >=20 A great mentor of mine once said... "Practice makes Perfect? NO! Unattainable. [pause] Practice makes *improvem= ent*." Perfection versus Improvement. I would be hard-pressed to accept any argument that a regression has occurr= ed. > I really really don't want to have to subject installer changes to explic= it approval requirements, Threats won't help your cause. Civility is key. > but *please* request review of non-trivial changes before commits, especi= ally to the disk partitioning code, Didn't touch your disk partitioning code. I have zero plans to. You can keep it (I'll just replace it in-whole when I= have something better). > and especially again before insta-MFCing them to a stable branch right be= fore a release. Gleb gave me insta-MFC approval. > It is much, much better than having to do this after the fact as > we are doing now. What we are doing doesn't need to be done (period). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D720FC60628>