Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jun 2005 21:50:55 +0200
From:      =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/ata ata-queue.c
Message-ID:  <04E48272-9625-406C-AF58-BA1A554FFC89@FreeBSD.org>
In-Reply-To: <200506281521.00598.jhb@FreeBSD.org>
References:  <200506280906.j5S96qIi053675@repoman.freebsd.org> <200506281310.50238.jhb@FreeBSD.org> <8EFCED13-E340-4C7D-A13B-3A5B01C4241E@FreeBSD.org> <200506281521.00598.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 28/06/2005, at 21:20, John Baldwin wrote:

> On Tuesday 28 June 2005 02:24 pm, S=F8ren Schmidt wrote:
>
>> On 28/06/2005, at 19:10, John Baldwin wrote:
>>
>>> On Tuesday 28 June 2005 11:30 am, S=F8ren Schmidt wrote:
>>>
>>>> On 28/06/2005, at 15:51, John Baldwin wrote:
>>>>
>>>>> On Tuesday 28 June 2005 05:06 am, SXren Schmidt wrote:
>>>>>
>>>>>> sos         2005-06-28 09:06:52 UTC
>>>>>>
>>>>>>   FreeBSD src repository
>>>>>>
>>>>>>   Modified files:
>>>>>>     sys/dev/ata          ata-queue.c
>>>>>>   Log:
>>>>>>   Zero donecount on auto request sense.
>>>>>>
>>>>>>   PR:             81450
>>>>>>   Approved by:    re@ (scottl)
>>>>>>
>>>>>
>>>>> Are you going to commit this to 5.x now as well?  FWIW, the patch
>>>>> in question
>>>>> was straight from the bug report as well.
>>>>>
>>>>
>>>> Well, I thought that the plan was to have 6.0 be the solution to =20=

>>>> 5.x
>>>> problems ;)
>>>>
>>>> Anyhow if/when I'll commit anything to 5.x, it will be the ATA =20
>>>> driver
>>>> from 6.0/current.
>>>> The problem being that the ABI for atacontrol etc has changed so it
>>>> kindof breaks the charter of -stable IMHO.
>>>> Other than that I have the bits sitting here on my lone -stable box
>>>> just waiting for a push on the big red commit key :)
>>>> .
>>>> - S=F8ren
>>>>
>>>
>>> Well is it ok if I merge just this change to 5.x then?
>>>
>>
>> As I've stated earlier I don't support what's been put into 5.x to
>> "fix" bugs.
>> ATA mkIII is the fix for the 5.x problems/bugs from this end, so you
>> can do exactly what you want on the ATA code in 5.x as I don't really
>> care :)
>>
>
> I'll be sure to remember that helpful attitude the next time you =20
> have an issue
> with one of your production machines that I could help with.  Also, =20=

> given
> that you committed the exact patch from the PR to HEAD and then =20
> claimed when
> you closed the PR prematurely that it was "solved (differently) in -=20=

> current"
> that was very rude to the submitter who took time to find a bug in =20
> *your*
> code and submit a working patch to fix it.

Just to give the balance here I have mailed with the submitter and =20
excused that it wasn't in -current but only in my local tree, shit =20
happens you know..

> I've also offered numerous times to do the actual commit of the fix =20=

> to 5.x if
> you would give it a quick glance over but you always responded to =20
> both me and
> the submitter by saying that the bug was already fixed in ata mkIII =20=

> and
> wouldn't comment on the validity of the patch other than to say =20
> that the bug
> was fixed differently in a different file in current.  Given that =20
> you just
> now committed the exact patch to HEAD, it would seem that, in fact, =20=

> ata mkIII
> did _not_ contain the correct fix as you had previously stated, and =20=

> I guess
> the fact that you committed it to HEAD finally gives me some actual =20=

> feedback
> on my requests for you to give it a quick review so the fix could =20
> be put in
> 5.x (since I was under the impression from your earlier e-mails =20
> that this
> issue was present on 5.x only).

Right, and all the mess is because it was decided to hack around in =20
ATA in 5.x whilst it was well known that the mkIII work was close to =20
being done. Mind you mkIII is all about fixing bugs in ATA, and =20
finetuning the infrastructure for future work.
That made me abandon ATA as is in 5.x, as I only have 24 hours a day =20
and a real life to take care off (I know that is not the common case =20
around here), and I simply don't have the time to sort out what hss =20
been randomly thrown into the pot, sorry. If the project cannot live =20
with that, I'll hand in my maintainer and commit bit any day, just =20
say when, I'm tired so tired already..

Now, I do have a 5.4 version of ATA from current, but its unclear to =20
me if it is wanted/allowed into 5.x, and until that eventual commit =20
happens I'm out of the loop on ATA in 5.x which I also stated =20
repeatedly here on the lists.

That all said I seriously think we all need a vacation and several =20
nights of good sleep :)

- S=F8ren






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04E48272-9625-406C-AF58-BA1A554FFC89>