lkml.org 
[lkml]   [2009]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] to rebase or not to rebase on linux-next
From
Date
On Mon, 2009-10-26 at 17:15 -0700, David Miller wrote:

> What you can't do is _PUBLISH_ this anywhere to a tree that people
> also do development against _UNTIL_ you get those acks and tested-by
> tags back from people.
>
> Once your acks etc. come in, you can pop all of those pending patches
> out of your tree, add the ack tags to the commit messages, then
> reapply them.
>
> Then you can push to your public tree, but no sooner.
>
> It really is that simple.

But you never answered my question? How long do you let it cook? I don't
have regular people that test my patches and pass tested by, whatever. I
get them here and there, sometimes I even a reviewed by. Most of the
time I just get silence.

My testing is mostly done in Ingo's test suite, and that happens after I
do my push to him. This works best for me.

Perhaps this doesn't bother your work flow, but it does mine. 90% (or
more) of the bugs in my code is found in Ingo's test suites. This means
I want to get it to him ASAP, and I do so by pushing it to him and
Cc'ing LKML. Then I can work on my next set of patches without worrying
about the last set I sent.

If I had to publish and let cook on LKML, then I would also need to keep
better accounting of what I have pushed out and what I have left to do.
My wife does the bills because I can't do accounting for crap. If I need
to account for patches that have been to LKML, and time them to know
when to push into some tree, I'm just destine to let a few patches slip
through the cracks.

-- Steve




\
 
 \ /
  Last update: 2009-10-27 02:31    [W:0.139 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site