Re: [Qemu-devel] Qemu development schedule?

["Jeebs" <Jeebs@yango.us>]

From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>

>> That's precisely the kind of attitude I was concerned about.
>
> So you are saying that because you like what the developers did so far,
> they please now should change their attitude according to your
> expectations?

No, I'm saying it because I am concerned that how Qemu has been developed in
the past will soon turn out to be a liability and impeed future progress.


>> At some point, successful open source projects have to transition from
>> the
>> 'free for all' attitude and organization to one with some actual
>> specified
>> goals and some organization.
>
> Why?

Because most non-'toy' projects fail if they don't adapt.

Writing a program for your own use is one thing.  Writing a program for more
general use by other, non-developer, people is an altogether different
thing.

Non-developers have different expectations.  Even if they don't expect 100% 
perfect results and bug-free code, they still have different expectations, 
and a 'developer' attitude rarely addresses those kinds of expectations.

I think I read somewhere in the archives that Fabrice (?) once said (not in
these exact words) that he was kind of dreading the day that Qemu was
'discovered' by public because their expectations would be much different
than those of the developers.

>> But at least a list of things to do and a schedule that says things like:
>> "When we add x, y, and Z and fix critical bugs 1, 2, 3, and 4, we'll
>> probably release the next version."  That wouldn't stop people from
>> adding
>> their own patches to fix their own problems.  Or maybe do a feature early
>> (provided more critcal stuff isn't being neglected).
>
> You are so welcome to do that.

Alright.

How do I do it?

Since I'm not a developer, how do I determine what to put onto the list of
things that need to be done?  A wee bit of a problem there.


>> If everybody is working on the 'sexy' stuff, then who is going to be
>> doing
>> the less glamorous stuff?
>
> Those who need it. I personally know people who learnt Tcl/Tk just for
> that stuff. I personally know people who can't write or fix programs, so
> they had to provide detailed bug reports, get updated sources or patches
> which they learnt to apply themselves, recompile, and test.

Which is fine for an early stage project.

>> I haven't done much 'development' since I was still using DOS.  I never
>> learned C++, Java, etc.  I stayed with C and I'm out of practice with it.
>> I
>> don't even have a C compiler installed anymore.
>
> Cool! Almost the whole source code of Qemu is in C!

But as I said, I'm out of practice.

Just last week I was trying to tell somebody about a library function, and I
had to actually go dig out my ref books just to see what header it's in and
what the params are.

After several years of no programming at all, I honest and truely seriously 
doubt you'd be happy with the quality of code that I'd be writing today.


> Again, why? If things get unusable for a developer, she will fix it. If
> things get unusable for a non-developer, he will try to find somebody who
> can and wants to fix it (often you can help the 2nd part).

Alright....

So these users complain.  Which has been starting to happen.

What are the chances those bugs will get fixed?  Especially if nobody is
bothering to even write them down?

Pretty much zero.

Unless a developer happens to decide that particular day to work on that 
particular bug, he's likely to forget about it.

If it's about his code, then he may remember a little longer.  But if it's 
somebody else's problem, then there's not much chance of him remembering it 
or working on it.

>> But if the project has the *eventual goal* of being more usable for a
>> wider
>> range of people, then at some point you have to change how things are
>> done.
>
> Why should the project have that goal? I am not Jesus nor RMS.

If it doesn't, then okay.  If the actual, official goal of the project is to
do it only as a developer project and not a user project, then okay.

But that needs to be stated, otherwise a whole lotta people are wasting
their time watching this project.


>> At the very least, you need a list of things that eventually need to be
>> done.
>
> No. You don't. Nobody has a (complete) list of things that need to be done
> for the Linux kernel.

Not a 100% list, probably not, no.  But they do (and did) have a rough list
of problems and things to do and test.