[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
sfr at canb.auug.org.au
Sat Jun 23 03:52:38 UTC 2012
On Fri, 22 Jun 2012 15:15:12 -0400 Paul Gortmaker <paul.gortmaker at windriver.com> wrote:
> 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.
This is not completely true. I do two builds (powerpc ppc64_defconfig
and x86_64 allmodconfig) after merging each tree ...
> 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.
See above. It currently takes between 4 and 10 hours to put linux-next
together. I could add another build between merges, but, at worse, that
could add 3 hours to my day's work. :-( A lot of the time, quite a few
of the trees are effectively empty, so that helps, but just before the
merge window opens, it can get quite bad :-( (made worse by people
rushing in last minute changes that break/conflict).
> > 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
Nothing is ever 100% green, failure free - I sometimes even find simple
build problems in Linus' tree :-(
> 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 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 :-)
Yes, "git rerere" is a life saver. But even so some conflicts are messy.
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the Ksummit-2012-discuss