Re: sparse maintenance pace?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 28, 2018 at 12:31 PM, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> So far as I've been told, it takes many many months for Luc to get a
> response on things he sends upstream, then gets some stylistic
> feedback, fixes it, resubmits, and then has to wait another couple of
> months. For this reason, people get fed up and are then inclined to
> diverge. This is a bummer, as it'd be preferable to have quick review
> cycles and thus continuous merging.

Oh, I agree. I think sparse maintenance does need to be more responsive.

>From personal experience, I can say that can be pretty hard to start
trusting others enough to just apply patches and take pull requests.
But it's important.

The maintainer does need to be a source of quality control, but at the
same time, it does very much require "trust others to just do the
right thing" too. The quality control may be about finding a quality
person, not about each patch.

Otherwise maintenance ends up being a huge bottleneck.

For the kernel, I obviously trust my maintainers - there's no way I'd
have any time at all if I didn't.

But part of that trust isn't even "is this right", but "will it be
fixed if it is wrong"?

And that trust generally just comes from "X has been around for a
while and shown him/herself to be reliable".  Once you get to that
point, you don't have to worry about the code changes as much, because
you can feel fairly confident that any problems found down the line
won't be _your_ problems ;)

In fact, the thing that drives *me* to swearing and being an asshole
top-level maintainer is generally not "a bug happened", but "a bug
happened and the source of the problem didn't take responsibility".
That will absolutely make me swear at a maintainer.

Bugs and mis-designed happen. They can be annoying and irritating and
embarrassing. But they are also just reality of any development.

So I do think Chris should take patches from Luc in particular more
aggressively - and preferably just pull his tree. Or even have shared
maintenance of the whole tree.

Because Luc has definitely been around long enough that we know he
fixes any issues he has introduced.

               Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux