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

[Steven Rostedt]

On Sun, 2012-06-17 at 15:32 -0700, Olof Johansson wrote:
> The flip side is that this might not flow well with how some other
> subsystems are maintained today -- some maintainers like to keep a
> fairly open for-next branch that they later rebase and cull patches
> from closer to the merge window. That obviously won't work well for
> us. In some of those cases, having two branches (a for-next that's
> mostly open, and a "stable" for-next that has the patches that are now
> set in stone) would solve it, but some people might have reasons to
> not work that way? 

This is also why I think we need a linux-devel branch that holds
people's development branches. Everyone's allowed to rebase when they
want, add acked-by's and reviewed-by's and such. This would be for
rebasing in general. Basically, a playground to see what others think.

After you've had your code vindicated in the linux-devel branch, you can
then move it off to linux-next, where it wouldn't need to rebase
anymore.

I would even say that this could be for anyone, not just maintainers and
sub-maintainers. I push my tracing code to tip, and Ingo then adds it to
linux-next and to Linus. But I have lots of 'in-development' branches
that I would love to get tested by others before I push it to tip.
Having a linux-devel repo, where pretty much anyone can add to it, will
give everyone more visibility into what they are doing.

There will be some rules. If your branch fails to compile, or breaks
normal boot ups, or other peoples work, your branch will be reverted and
a nasty note will be sent to you. The 'master' branch will constantly be
rebased (do not develop on this repo, just test against it). It could
work similar to tip/master. It pulls in the various branches, and if one
is broken, it blocks it for the time being until that branch is working
again.

Thus, the master branch would start with linux-next, and then start
pulling in development branches from developers that have requested it.
Your code will be tested before it is pushed to the main repo, and if it
passes the local tests, then it will go public. If it is found to break
something, a new rebase is started again from linux-next and the process
repeats.

I'm not sure how to deal with conflicts, probably just fix it up as it
is needed, and have scripts to help redo them. There's ways around
that :-)

-- Steve