On Tue, 29 Jul 2008, Jesse Barnes wrote:I don't think anybody wants it to go away. The question in my mind is more along the way of how/whether it should be changed. There was some bickering about patches that weren't there, and some about how _partial_ series were there but then the finishing touches broke things. I don't personally really think that it's reasonable to expect everything to be in -next (but hey, I'm willing to be convinced otherwise). And don't get me wrong - it certainly wouldn't bother _me_ to have everything go through next, since it just makes it likelier that I have less to worry about. BUT. I do think 'next' as it is has a few issues that either need to be fixed (unlikely - it's not the point of next) or just need to be aired as issues and understood: - I don't think it does 'quality control', and I think that's pretty fundamental. Now, admittedly I don't look much at the patches of people I trust either (that's what the whole point of that 'trust' is, after all - to make me not be the part that limits development speed), but that's still different from 'largely automated merging'. So I _do_ check the things that aren't obvious "maintainer works on his own subsystem" or are so core that I really feel like I need to know what's up. I seldom actually say "that's so broken that I refuse to pull it", but I tend to do that a couple of times per release. That may not sound like much, but it's enough to make me worry about 'next'. I worry that 'it has been in next' has become a code-word for "pull this, because it's good", and I'm not at all convinced that 'next' sees any real critical checking. - I don't think the 'next' thing works as well for the occasional developer that just has a few patches pending as it works for subsystem maintainers that are used to it. IOW, I think 'next' needs enough infrastructure setup from the developer side that I don't think it's reasonable for _everything_ to go through next. And that in turn means that I'm not entirely thrilled when people then complain "that wasn't in next". I think people should accept that not everything will be in next. But I don't think either of the above issues is a 'problem' - I just think they should be acknowledged. I think 'next' is a good way for the big subsystem developers to be able to see problems early, but I really hope that nobody will _ever_ see next as a "that's the way into Linus' tree", because for the above two reasons I do not think it can really work that way. Linus --
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Michal Piotrowski | Re: Linux 2.6.21-rc4 |
| Joe Peterson | Re: 2.6.25.3: su gets stuck for root |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Emil S Tantilov | Re: WARNING: at include/net/sock.h:417 udp_lib_unhash |
