Subject: Re: How to debug linux-next?

From: Takashi Iwai <[email-masked]>
Date: Thu, 31 Jul 2008 18:59:24 +0200

At Thu, 31 Jul 2008 18:54:05 +0200,
Nico -telmich- Schottelius wrote:
> 
> Takashi Iwai [Thu, Jul 31, 2008 at 06:36:38PM +0200]:
> > Nico -telmich- Schottelius wrote:
> > > Takashi Iwai [Thu, Jul 31, 2008 at 05:58:46PM +0200]:
> > > > I also would love to have a continuous git tree, but I guess it's
> > > > pretty hard for linux-next after some time.  git-merge doesn't always
> > > > track rebased trees perfectly, and we have also quilt trees in
> > > > addition.  Moreover, sometimes some subtrees have to be dropped
> > > > temporarily for fatal conflicts.
> > > 
> > > Yes, imho rebase is something that must create pain, as it changes the
> > > history (independent of git and linux).
> > > For quilt, I did never use it -- not sure how those trees could be
> > > integrated.
> > > 
> > > And dropping trees: Would not ignore those branches for
> > > merging help? Or if stuff has to be removed, to revert changes?
> > 
> > Hm, what are the difference between them?  Since linux-next is
> > re-generated at each time, both should mean the same...
> 
> A revert is recorded in the history.
> A rebase isn't (and isn't thought to).

Ah, so you mean to revert the whole tree commit?
Not sure whether it looks nice...

> > > > BTW, you can try to merge the tree by yourself. 
> > > 
> > > Well, yes, but that breaks my idea of having all trees based on the same
> > > history: If I want to see, what the agp team did after v2.6.29 was
> > > released and compare it to what I've -- I cannot do it, because their
> > > v2.6.29 base is a different one than mine.
> > 
> > Well, I meant you can try to get some continuous history by yourself
> > to solve your problem.  You know 20080729 is good, and 20080731 is
> > bad, and you do want a continuous history between them.  Then you can
> > start from the good point and merge the next-tree itself manually
> > until the bad point.
> 
> That maybe a good idea to fix debug the issue now ... although
> I still hope, we'll get a more generic way to fix such things
> (-> when there are more linux-next testers, more such problems
> will arise).

Yes.

> I am still not sure, what would allow me the easiest way of debugging,
> will perhaps have a deeper look at it later.

If it's about input-layer change like Andrew's case, Dmitry's patch
should solve.  Or, revert the commit 0571c5d20aca7...

> > I didn't suggest to keep maintaining self-made linux-next tree, of
> > course :)
> 
> In fact, I am very happy for the work Stephen does. It really allows
> testing new stuff quite easily.

Definitely.

Takashi