[Yaird-devel] Re: Bug#345067: ide-generic on poweprc

[Sven Luther]

On Thu, Mar 09, 2006 at 10:03:18AM +0100, Jonas Smedegaard wrote:
> On Wed, 8 Mar 2006 23:29:14 +1000
> Anthony Towns <aj at azure.humbug.org.au> wrote:
> 
> > On Tue, Mar 07, 2006 at 02:35:59PM -0500, Raul Miller wrote:
> > > On 3/7/06, Sven Luther <sven.luther at wanadoo.fr> wrote:
> > > > On Tue, Mar 07, 2006 at 07:20:31PM +0100, Jonas Smedegaard wrote:
> > > > > Please see http://wiki.debian.org/LinuxKernelIdeProblem that I
> > > > > created today and have invited the kernel team and udev
> > > > > developers to improve on.
> > > > An assembly of patent ...
> > > It looks to me like that's a wiki page.
> > > In other words, you can fix problems on it directly without needing
> > > to ask for help or permission.  
> > 
> > Which Sven's since done, leading the page to begin with:
> 
> [snip ranting]
> 
> > Jonas's last revision, without Sven's comments, is available at:
> > 
> >   http://wiki.debian.org/LinuxKernelIdeProblem?action=recall&rev=4
> > 
> > From what I can see of that, the maintainer seems on track to solve
> > the problem. I don't see any great reason to overrule that process.
> 
> However fond I am of wiki, I tend to agree with Ian that wiki is
> unsuitable for too diverging opinions. I was trying to track the chain
> reaction of problems/workarounds involved, while it seems Sven use same
> page to proove non-existance of current kernel only.

Jonas, ... 

you are free to look into older kernels and prove me, as i did prove you even
if you have trouble accepting it, that there ever was such a bug, but i don't
think it is acceptable to continue on this path now that it has been proven
you are wrong, without backing it with substancial evidence. This whole issue
degenerated because back in december folks where doing wild guesses to solve
half-understood and non-reproducible bug reports, and didn't bother to look at
the actual code.

Furthermore, the design of both yaird and the kernel ide layer make it very
hard to believe such a bug existed. It could be, but would be a bug in the
kernel to be solved ASAP, not something to work around in the ramdisk tools,
and i believe the hacky workarounds, by hiding the problem, where even more
nefast than they helped in any way.

> I'll continue working on the wiki, but let's debate through email as

I would appreciate if you could clean the wiki, remove all my ranting, and
your wrong assumptions, and put my analysis to the forefront. You probably
noticed that i modified the mention of the ide-core thingy after having
examined the symbols in the modules (i asked for an x86 modules.dep for 2.6.8,
2.6.12 and 2.6.15, but nobody provided it to me yet, maybe you can), and did
so in a non-controversial way i hope.

I am all for that we look at the issues of back then and try to analyse what
happened, but i have some doubt of the usefullness of it, still you have to
accept your part, and admit you have been wrong, or we will not be able to be
constructive on this issue if you stubornly continue to try to prove you where
right.

> Ian recommended, and use wiki only by referring to explicit revisions
> to avoid confusion.

Let's work together to clean the wiki instead, but please no more wild guesses
without at least marking it as wild guesses or giving a semblance of hint of
some reasoning behind it.

There is a worse problem though. Have you heard of your upstream since
december ? It seems to me not, and beyond the natural worriness of wondering
what happened to him, and hoping nothing worse than disinterst for computer
things are the cause, it poses the question of the future of yaird.

Are you ready and willing to take over upstream maintainership ? From past
comments i kind of doubt that, so what are we going to do ? 

Are you ready to move that responsability to the kernel team, or a common
yaird team ? I would gladly help out, as it seems clear that i understand how
things work either in yaird or the kernel itself better than you, but i don't
speak perl, so we need a real perl native to join the project. This could be
the solution, with you doing the day-to-day maintainership, me investigating
the problem, and someone else doing the actual perl implementation, at least
at first until i become familiar with perl, or Erik surfaces again ? 

What do you think of it ? 

Friendly,

Sven Luther