Re: [Xen-devel] [PATCH v9 02/10] scripts: Coccinelle script to use ERRP_AUTO_PROPAGATE()

[Vladimir Sementsov-Ogievskiy <vsementsov@xxxxxxxxxxxxx>]

20.03.2020 16:58, Markus Armbruster wrote:
> Vladimir Sementsov-Ogievskiy <vsementsov@xxxxxxxxxxxxx> writes:
>
> > 19.03.2020 13:45, Markus Armbruster wrote:
> > > Vladimir Sementsov-Ogievskiy <vsementsov@xxxxxxxxxxxxx> writes:
> [...]
> > > > So, understanding that there no such cases in the whole tree, and even
> > > > if your patch works faster on the whole tree, I still don't want to
> > > > drop inheritance, because it's just a correct thing to do. Yes, we've
> > > > added ____ helper. It helps to avoid some problems. Pair-inheritance
> > > > helps to avoid another problems. I understand, that there still may
> > > > other, not-covered problems, but better to be as safe as possible. And
> > > > inheritance here is native and correct thing to do, even with our ____
> > > > additional helper. What do you think?
> > > I wouldn't call it correct.  It's still unreliable, but less so than
> > > without the function name constraint.  That makes it less wrong.
> > Agree.
> >
> > > 100% reliable would be nice, but not at any cost.  Something we're
> > > reasonably confident to get right should be good enough.
> > >
> > > To be confident, we need to understand the script's limitations, and how
> > > to compensate for them.  I figure we do now.  You too?
> > I will not be surprised, if we missed some more interesting cases :)
> > But we should proceed. What is our plan? Will you queue v10 for 5.1?
> v10's PATCH 1+2 look ready.  The error.h comment update could perhaps
> use some polish; I've focused my attention elsewhere.
>
> PATCH 8-9 are generated.  They should never be rebased, always be
> regenerated.  We compare regenerated patches to posted ones to make sure
> they are still sane, and the R-bys are still valid.  I can take care of
> the comparing.
>
> I'd like to have a pull request ready when the tree reopens for general
> development.  Let's use the time until then to get more generated
> patches out for review.
>
> If I queue up patches in my tree, we shift the responsibility for
> regenerating patches from you to me, and create a coordination issue:
> you'll want to base patch submissions on the branch I use to queue this
> work, and that's going to be awkward when I rebase / regenerate that
> branch.  I think it's simpler to queue up in your tree until we're ready
> for a pull request.
>
> When you post more patches, use
>
>      Based-on: <20200317151625.20797-1-vsementsov@xxxxxxxxxxxxx>
>
> so that Patchew applies them on top of this series.  Hmm, probably won't
> do, as PATCH 9 already conflicts.
>
> You could instead repost PATCH 1+2 with each batch.  I hope that's not
> too confusing.
>
> I trust you'll keep providing a tag reviewers can pull.
>
> I suggest to ask maintainers to leave merging these patches to me, in
> cover letters.
>
> Makes sense?
Hmm.

I remember what Kevin said about freeze period: maintainers will queue
a lot of patches in their "next" branches, and send pull requests at start
of next developing period. This highly possible will drop r-bs I can get now.
And reviewers will have to review twice.

And for the same reason, it's bad idea to queue in your branch a lot of patches
from different subsystems during freeze.

So, just postpone this all up to next development phase?


--
Best regards,
Vladimir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel