[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

[Rafael J. Wysocki]

On Tuesday, June 19, 2012, Steven Rostedt wrote:
> On Tue, 2012-06-19 at 23:17 +0200, Rafael J. Wysocki wrote:
> 
> > It makes sense to create a patches-that-came-too-late branch in your tree and
> > put those things in there, so that they can be moved to the linux-next branch
> > when the merge window closes.  I'm not sure what the advantages of having a
> > central repository of such things would be, though.
> 
> That's not what I'm proposing.
> 
> Yeah, things are being thrown around a lot here, but that's good,
> because this is a 'discuss' list :-)
> 
> I'm not suggesting that we have a linux-devel that is there for you to
> put things in that are for linux-next. If you had patches ready for
> linux-next and missed the merge, you only need to wait till Linus's
> merge window closes and linux-next will be open again.
> 
> Which means what I said before did not make sense. The merge window for
> linux-next would be much longer than linus's tree. It would open when
> Linus closes his merge window, and it should close around -rc5 or -rc6.
> That is, if you see -rc5 came out, you have a couple of weeks left to
> get stuff into linux-next before it closes.
> 
> Now for linux-devel that I'm proposing is for much earlier than when you
> are ready for linux-next. And may not be for everything. If you are just
> doing some minor updates to your subsystem, there's no advantage in
> getting that out to linux-devel instead of just pushing it to linux-next
> when it is ready.
> 
> What I want linux-devel for is the bigger changes. Things where you do
> rewrites. It would have been nice to see the new printk() go into such a
> repo that way we could have played with it more before it hit linux-next
> or mainline. linux-devel should be for just that. Development, not
> maintenance.
> 
> Sometimes its nice to have a general repo were you can dump out your
> code and say "here's what I've been doing, does this all work for you?".
> This is the place to send code that is still in RFC mode. Patches are
> great, but I really believe that you will get more people testing it if
> you shared the repo that others have their development code in too.
> 
> That's what I'm proposing. Not just a N+1 repo (put it in X before it
> goes to Y then we can ship it to Z). But something like the old -mm was.
> Where code can literally sit for years before it finally makes it to
> mainline.

I see.

I'm not sure if that's going to be practical for rewrites, though, because
I'm afraid it won't get too much testing.

It may be good for keeping features under development together, so that people
know in advance what conflicts are likely to happen and so on.

Thanks,
Rafael