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

Stephen Rothwell sfr at canb.auug.org.au
Sat Jun 23 03:52:38 UTC 2012


Hi Paul,

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.

Indeed.

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

-- 
Cheers,
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/attachments/20120623/0837f37a/attachment.sig>


More information about the Ksummit-2012-discuss mailing list