Date: Mon, 5 May 2003 01:27:46 -0600 From: Scott Long <scott_long@btc.adaptec.com> To: "Greg 'groggy' Lehey" <grog@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: Deliberately breaking software (was: cvs commit: src/sys/dev/ vinum vinumioctl.c) Message-ID: <20030505072745.GD83498@hollin.btc.adaptec.com> In-Reply-To: <20030505072515.GC84427@wantadilla.lemis.com> References: <20030505072515.GC84427@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It's 3:30am and I'm trying to read email that concerns code that doesn't
even compile at the moment. Please take this off the public lists and fix
the compile problems in the tree.
Thanks!
Scott
On Mon, May 05, 2003 at 03:25:15AM -0400, Greg 'groggy' Lehey wrote:
> On Monday, 5 May 2003 at 8:34:41 +0200, Poul-Henning Kamp wrote:
> > In message <20030505055618.GA84427@wantadilla.lemis.com>, "Greg
> 'groggy' Lehey"
> > writes:
> >
> >>>> Forgotten by: phk
> >>>
> >>> Nope, I knew about it.
> >>
> >> And you broke it anyway? Why?
> >
> > No, vinum disregarded how our disk system worked and implemented only
> > part of the API, that is why you needed a kludge option ("-v") in
> > newfs for vinum. Compare this to ccd which did not need it.
>
> ccd implemented disk labels and partitions. That didn't make sense.
> But that doesn't answer the question: why did you break something that
> was working, even if you think the solution was wrong?
>
> >> I don't recall that.
> >
> > _That_ is not my problem.
>
> Yes, it is. You're making claims which you can't substantiate.
>
> >> Anyway, you can't force people to maintain software.
> >
> > I find it deeply ironic that you say this to distance yourself from
> > your responsibility as author of vinum, right after trying (and
> > before for that matter, you try again in this email) to force
> > me into fixing vinum for you.
>
> I never tried to force you to fix Vinum. As should be adequately
> obvious, you deliberately broke a working interface.
>
> >> I relinquished my maintainership for Vinum simply because I
> >> couldn't work with you.
> >
> > That's your choice.
>
> It's one that many people make. You are a disruptive influence on the
> project.
>
> > Right now, you still do not use disk_create() to create proper
> > disk-device in vinum, and that means that features which work with
> > other disk devices in the system do not work with vinum.
>
> Let me rephrase that. I suspect what you meant to say starts with
> "When I changed the system in February, changing drivers to use
> disk_create(), I missed out Vinum because...". I'd like to know your
> reason. If you want to claim that I'm the implicit maintainer, why
> didn't you tell me about it?
>
> And who else can do it? As others have observed, you're referring to
> undocumented interfaces. There isn't a single comment in the
> function. How do you expect anybody else to know how to use it?
>
> > When do you plan to fix that ?
>
> When it's documented.
>
> > Or should I simply tell people that disk encryption does not, and
> > will not ever work with vinum ?
>
> Of course not. If you think it's important, fix it. And if you wrote
> disk_create, document it.
>
> As mbp observes, this doesn't belong on this list. If you can think
> of anything useful to say, please do it in private. Feel free to copy
> -core.
>
> Greg
> --
> See complete headers for address and phone numbers
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030505072745.GD83498>