Re: Porting old hardware from ide to libata (was [PATCH 0/7] ide: locking improvements)

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Tuesday 14 October 2008, Alan Cox wrote:
> O> You may want to dig into archives and learn about history of libata.
> > Especially under what conditions it has been ACK-ed and merged _five_
> > years ago.  Just to quickly recall, there were two such conditions:
> > 
> > * PATA support would be moved from IDE to libata in an evolutionary way.
> 
> IDE stood stale for a year while you vanished (to CERN ?) so the rest of

The real issue is that some corporate people are taking things for granted
so when the pace slowed down (after I "vanished", which was a known fact,
and had a less of my time than before to work on IDE) they started pushing
more pressure on me instead of considering constructive solutions, i.e.
it is not like I ever got an offer from somebody else to take over the code
or to help with the code etc.

[ It is also worth to notice that I never promised to be the one doing
  all the IDE -> libata work so if somebody thought otherwise it was only
  his unrealistic expectation (especially given timescale and the fact
  that because of 2.5.x IDE revert, early 2.4.x -> 2.6.x IDE stabilization
  required a lot work). ]

Yes, the code "stood stale" but only after flamewar + libata PATA + kick
from some fellow maintainers (well, I learned that the outcome of the game
has already been decided months ago and thought that me vs Red Hat was a
lost cause + also that I was a real idiot from the start :-).

[ "stood stale" is not completely correct since the patches were
  being (slowly) reviewed and Andrew has been pushing them upstream ]

> the world decided to get on with it. As it happens an evolutionary change
> would have made no sense as the mentality of the code is [thankfully]

It is not like there wasn't a sane roadmap, TODOs, repeated descriptions
of needed tasks, just nobody from corporate Linux world was interested in
doing any real work (except Tejun).  This wasn't so bad in itself because
I would still be able to handle most of it.  The real problem was that
I was forwarded unprocessed bugreports or half-baked patches and actually
expected/pressed to also handle all that at the same time.  While there
were absolutely no people around to help with it.

> quite different and we could eject an enormous amount of crud in the
> process.

I think that there is no point in discussing it any further since we are
unlikely to ever come to similar conclusions.

Lets just peacefully disagree on this case and move on other things.