On Tuesday 29 January 2002 08:40 am, Alan Cox wrote:
> > for code areas where there is not active maintainer or the maintainer has
> > ignored patches? Eg. the majority of the kdev transition patches went in
> > smoothly.
>
> No you merely aren't watching. Most of the maintainers btw are ignoring 2.5
> if you do some asking. And a measurable number of the listed maintainer
> addresses just bounce.
I'm under the impression Michael Elizabeth Chastain is one such burned out
maintainer, but hasn't been able to hand over maintainership because Linus
keeps dropping his patch to change the maintainers file to say "Peter
Samuelson", and he eventually just gave up trying.
I could be wrong about this. Ask him. Or maybe his maintainer hand-over
patch needs more code review?
> > Another reason is that you do much more housekeeping in areas that are
> > not actively maintained. But wouldnt it be better if there were active
> > maintainers in those areas as well so you could spend more time on eg.
> > doing the kernel-stack coloring changes?
>
> There never will be maintainers proper for large amounts of stuff, and the
> longer Linus deletes and ignores everything from someone new the less
> people will bother sending to him.
Case in point:
--- linux/arch/i386/boot/bootsect.S.old Tue Jan 1 19:41:22 2002
+++ linux/arch/i386/boot/bootsect.S Tue Jan 1 19:44:02 2002
@@ -158,9 +158,7 @@
movw $sread, %si # the boot sector has already been
read
movw %ax, (%si)
- xorw %ax, %ax # reset FDC
- xorb %dl, %dl
- int $0x13
+ call kill_motor # reset FDC
movw $0x0200, %bx # address = 512, in INITSEG
next_step:
movb setup_sects, %al
Dumb little nit I noticed a few weeks ago, but never bothered to follow up
on, because it's just not worth it. Not that potentially saving 3 bytes out
of the boot sector is a BAD thing, but it's not good enough to be worth the
effort anymore. Warning fixing patches are largely the same way: easy to do,
but why?
This didn't strike me as a healthy development, really...
> Just look at the size of the diff set
> between all the vendor kernels and Linus 2.4.x trees before the giant -ac
> merge.
>
> Think gcc, think egcs. History is merely beginning to repeat itself
I was actually hoping to AVOID that. (There IS still time. We're not that
badly off. Yet. I'm just a bit nervous about direction. The kind of
stresses I've seen seem (to me) unlikely to improve with time...)
And we ARE using a patch penguin. You were around, and Dave is around. I'm
kind of confused at the level of resistence to formally recognizing what
basically IS current practice, and has been for YEARS. (The reason for
naming the position is we can't just say "alan's tree" anymore. The position
went from one person to another person, and as such the position seemed to
need to be recognized as being separate from the individual. I didn't expect
to hit a brick wall on that. It didn't seem like a revolutionary idea to
me...)
> Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:08 EST