Re: stable? quality assurance?

Martin Steigerwald
2010-09-04T20:21:51Z

[-- Attachment #1: Type: Text/Plain, Size: 6220 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]