Re: stable? quality assurance?

[Martin Steigerwald]

Am Samstag 04 September 2010 schrieb Stefan Richter:
> Martin Steigerwald wrote:
> > I think main problem is that the current development process does not
> > give time for quality work and bug fixing.
> 
> This has little to do with process.
> 
> Put simply, the paid developers work on what they are paid for.  The
> volunteers work on what they are interested in.

And they are paid for features instead of fixing bugs? I doubt enterprise 
customers have this preference. I admit, they have no reason to pay for 
fixing my bug, unless they experience it too, however.

> If you feel that too little work is spent on stabilization and bug
> fixing, pay someone or take matters into your own hand.  I.e. report
> bugs and work with the developers to get the bugs fixed.

I do already for the bugs I encountered.

> The current development process OTOH gives plenty of time for quality
> work and bug fixing:
> 
>   - There are several stages at which new code can be tested:
>     When it lives in subsystem development trees,
>     when it has been pulled into the linux-next tree,
>     when it has been pulled into Linus' tree.
>
>   - Bug fixes are pulled by Linus almost any time whenever they are
> ready. (Of course, since fixes can and do introduce regressions too,
> only critical fixes are accepted in later -rcs.)
> 
>   - New code submissions are pulled by Linus in a fairly reliable cycle
>     with reasonable frequency (less than three months).  That way,
>     developers know that if their stuff did not quite cut it for
>     mainline merge in month N, they know they can try again in month
>     N+2 or N+3.  They are not left to guess whether their next chance
[...]

I will think a bit more about this. But my first impression is that all of 
these provisions are currently in conflict with time for feature work. If 
there is no stabilization or sorta of freeze period, the speed won't calm 
down in order to give stabilizitation a realistic chance.
 
> > But is that a *given* that no one actually has any influence to? Is
> > collecting changes for next kernel like rain that either pours down
> > or not - usually pours down in this case like in August in Germany
> > ;)? Who feeds Linus with new stuff during the merge window? From
> > what I understand of the Linux development process its mainly the
> > subsystem maintainers and Andrew Morton.
> > 
> > What if those people stop collecting new stuff for Linus except
> > bugfixes about two or three weeks before the next kernel is relased?
> 
> Most of the maintainers are responsible enough to put only stuff into
> linux-next which belongs there, i.e. tested, release-ready stuff. 
> Likewise with submissions to Linus during the merge window.
> 
> Only some maintainers do in fact try to submit rushed, untested crap.
> Sometimes they get caught red-handed.
> 
> The release-ready submissions that come via responsible maintainers
> still contain some regressions though.  This is inevitable.  There are
> less regressions if there are more enthusiasts who test development
> trees and linux-next.  There are less regressions in Linus' releases
> if there are more enthusiasts who test -rc kernels.  (And submit good
> bug reports and work with the developers on them.)  And vice versa.
> 
> Process does not do much to prevent bugs or fix bugs.  People do. :-)

Yes, my suggestion do not guarantee that people do report and fix bugs. But 
it gives more room for doing so, especially regarding fixing the open and 
known regressions. Again two of those that I mentioned initially have been 
reported by people *during* the rc phase already. Still the stable kernel 
did not receive the bug fix patch for the nastier one of it in time: 

That is what I am concerned about. If people do test, do report and 
someone even does a patch and yet its not in the stable kernel then, what 
for did they do it?

Okay, it was in 2.6.35.1, but when a major and reported regression is only 
fixed in stable patches I still think that any release without at least two 
or three stable patches should not be called stable at all - its just 
misleading then. And I think I am perfectly entitled to that oppinion. 
Anyway I will relabel kernels in my mind and not consider a kernel without 
stable patches stable anymore. I did so theoretically before already but 
now I experienced it for myself the first time.

> However, you can hardly tell people to implement less features and fix
> more bugs if they don't owe you anything.

Sorry for the demanding tone in my post that initiated the thread, but in 
the post you are answering too I merely made a suggestion. No one does owe 
me anything and I am aware of that.

But still even when I do not prepend each of my mails with a list of what 
I have done for the kernel - which is clearly less than what any core 
kernel developer or even a casual kernel developer did for the kernel  - I 
still can make a valuable suggestion.

That said I compiled a kernel a day or two for some time to help Ingo 
Molnar with testing an use case for his CFS scheduler. And am I regularily 
testing new TuxOnIce kernels and report back to Nigel how they fare. I 
report bugs for other open source projects like KDE or Debian as well and 
contribute a bit here and then, like my first debian package "fio".

And this work mostly has been enjoyable. Neither Ingo, nor Nigel, nor Jens 
Axboe asked me what I did for the kernel prior to working with me. They 
have just been happy for the feedback I gave.

I admit my initial post did well to provoke the kind of "what did you do?" 
feedback as it actually was demanding. But then I really was frustrated 
with the kernel and I think sometimes an oppinionated post like my 
"stable? quality assurance?" can be quite good. If I think a kernel is 
crap, why should it be prohibited that I tell it to their developers? At 
least I learned a lot and even started bisecting that bug even though it 
takes an insane amount of time to do so.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Attachment: signature.asc
Description: This is a digitally signed message part.