Re: 2.6.17-rc2-mm1

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

 



"Randy.Dunlap" <[email protected]> wrote:
>
> On Fri, 28 Apr 2006 07:41:52 +1000 Grant Coady wrote:
> 
> > On Thu, 27 Apr 2006 12:19:30 -0700, Andrew Morton <[email protected]> wrote:
> > 
> > >I don't like dropping patches.  Because then the thing needs to be fixed up
> > >and resent and remerged and re-reviewed and rejects need to re-fixed-up and
> > >this adds emailing overhead and 12-24 hour turnaround, etc.  I very much
> > >prefer to hang onto the patch and get it fixed up.  This means that I
> > >usually have to do the fixing-up.
> > 
> > Perhaps dropping patches with obvious faults with some feedback 
> > to submitter may reduce your workload ;)  And is slowing down the 
> > merge a little in these cases such a bad thing if it improves 
> > patch quality over time?
> 
> True dat.  That's what I would do.  :)

As I say - I prefer to keep moving in the forward direction.  So if a patch
needs coding-style cleanups, warning fixes, bugfixes, etc it's usually
quicker to just fix the thing immediately rather than send it back, wait
and then redo everything.  The submitter sees the fixes and hence will
Never Do That Again (right?)

None of this is a particular burden for me - it'd average an hour a day,
tops.  My main reason for the big whine is that this defect rate indicates
that people just aren't being sufficiently careful in their work.  If so
many silly trivial things are slipping through, then what does this tell us
about the big things, ie: runtime bugs?

> But I seem to need more sleep than Andrew does.

There's plenty of time for that in the grave.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux