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

Paul Gortmaker paul.gortmaker at windriver.com
Fri Jun 22 19:15:12 UTC 2012

On 12-06-18 11:14 PM, Steven Rostedt wrote:
> 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

This sounds simple enough, but in practice there may be a significant
overhead in determining just whose branch caused the failure.  At least
that is the case with linux-next, where everything is pulled together
at once, and then dispatched for a day's worth of builds.

One way to have semi automated knowledge of which one failed, would
be looking at testing A, then A+B, then A+B+C, etc.  At 200-ish branches
being in linux-next, I'm not sure that would be feasible -- since it
currently takes a good part of the day just to get through all the test
builds linux-next does now once.  Reducing the scope of the builds per
step would help, but if you go too far that way, then the tests don't
cover enough and you just end up giving yourself a false sense of
everything being all roses.

On the other hand, if you don't do the semi-automated per-step approach,
then it falls back to a human doing some level of triage or bisect.
This can eat a lot of time -- I'm currently mulling over ways to add
some more automation to the linux-next triage work I was doing earlier,
because it was timewise expensive.

> 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.

Somewhat implicit in the above, is assuming linux-next is a 100% green,
failure-free baseline.  The reality is that regressions appear in
linux-next and sometimes take weeks to get resolved, especially if
they are on one of the lesser used architectures.  Which is just to
say that such a devel tree would have dependencies on the state of
linux-next, and that the tests done on the devel tree would have to
be a subset of what is known to normally be green on linux-next.

I'm not saying the devel branch is bad, but just pointing out a couple
things that will become apparent once it gets implemented.


> 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
> _______________________________________________
> Ksummit-2012-discuss mailing list
> Ksummit-2012-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss

More information about the Ksummit-2012-discuss mailing list