[alsa-devel] [PATCH 2/2] ALSA: pcm: add arrangement for applying appl_ptr

[Takashi Iwai]

On Fri, 26 May 2017 10:46:07 +0200,
Takashi Sakamoto wrote:
> 
> On May 26 2017 16:10, Takashi Iwai wrote:
> > On Fri, 26 May 2017 08:54:27 +0200,
> > Takashi Sakamoto wrote:
> >>
> >> On May 26 2017 15:47, Takashi Iwai wrote:
> >>>>> Queued now, but will be likely declined later due to the rewrites of
> >>>>> the code.
> >>>>
> >>>> Due to your recent work under reviewing?
> >>>
> >>> Yes, the code might be changed heavily.
> >>> Don't touch a too hot spot if it were only a cleanup.
> >>
> >> I've already reviewed it but postpone my reply to this evening. (I'm
> >> in paid work now.)
> >>
> >> Your patchset looks a middle of work. It includes the lack of changes
> >> for each drivers, thus not bisect-able.
> >
> > Yes, it was mentioned so in the cover letter.
> >
> >> I think you will re-post the
> >> full series of patches several days after reviewed. Then you have
> >> chance to rebase it to recent HEAD of your tree, don't you?
> >
> > My patches are already ready.  I didn't post the full set just because
> > it's too much.  The patch "snippet" was shown as a demonstration.
> 
> Yes, like I did in my previous patchset.
> 
> > And, why do you think there is only one patchset?
> > Usually I write several different implementations and choose the best one
> > for submission.  That is, I already have a few other patchsets in my local
> > tree based on the current code base.  And even further works on PCM
> > code are pending.
> 
> I can easily imagine how you progress the work, because I have some
> topic branch in my local repository as well, for PCM core. They're
> also ready, like yours. However, I accept changes of HEAD of remote
> branch. HEAD tends to move regardless of my work. When posting my
> patchset, I always work to rebase to the HEAD. This often brings me a
> bit work, and next week I'll surely do it, but it's natural to me.
> 
> Here, I don't necessarily request you to merge them promptly. I'm just
> interested in your current situation, in short, the reason to postpone
> this patch. In my eyes, this patch surely brings conflict to your
> future patchset, but it has a small changes and the occurred conflict
> can be fixed quickly. I understand that you'd like to save the time
> for it.
> 
> > So which is easier to rebase and handle?  Which one has more
> > significant changes?  A single trivial cleanup patch, or the whole
> > several sets of patchsets?  The answer is clear to my eyes.
> 
> Hm.
> 
> It depends on the shape of patchset, regardless of the importance, in
> my humble opinion.
> 
> When it includes large changes, it takes longer time to review. When a
> patchset is splitted into small parts and posted sequentially with
> each of topics, reviewer finishes his or her work within shorter time
> relatively. I'll post my comments to your recent work later, but here
> your patchset looks to include refactoring, integration and more. It
> seems takes more time to merge into HEAD and I cannot post the series
> of my works (they depends each other) even if my patches are enough
> small. That's my concern here.

A pain-point at this time is that it's involved with other subsystems,
thus the interaction with them should be minimized.  Usually, I prefer
implementing things more gradually, e.g. add copy_kernel ops at first,
then refactor PCM core slowly.  But it'd require more interactions
with other subtrees as long as API change is required.  That's why I
chose the one-time change including refactoring.

That said, if API change is in play, this is the biggest blocker per
its nature, and it has the higher priority than other conflicting
changes (unless it's an urgent fix).


thanks,

Takashi