Re: [PATCH v2 07/28] Silicon/NXP: Implement SerialUartClockLib

["Leif Lindholm" <leif@nuviainc.com>]

On Thu, Apr 09, 2020 at 07:44:48 +0000, Varun Sethi wrote:
> > > Now, neither appears to have happened, as .c still comes before .inf 
> > > and paths are still truncated.
> >
> > I had executed the SetupGit.py script, I will check again.
> >
> > > But in addition to that, we realised that git happily ignores 
> > > settings for --stat. So, please, execute aforementioned script, but 
> > > then generate v3 with --stat=1000 --stat-graph-width=20.
> >
> > Ok. I will follow these steps as well.
> >
> > > For this particular patch, the side discussion on the edk2 portion 
> > > may make it redundant, so I'm deferring review.
> >
> > Right now, I am yet to work on the review comments of other edk2 patch 
> > and since it touches other platforms as well, it requires thorough 
> > vetting from other platform maintainers. It seems like that would take 
> > more time. If I send this patch series without removing DuartLib (i.e. 
> > drop patches 7, 8, 9 from this series), can you please merge. 
> > Parallelly, I will work on edk2 patch and once that is accepted, I
> > will send patches 7, 8, 9 after that in new series ?
> 
> >See comment in my previous email on merging code only to remove it
> >shortly afterwards.
> 
> We will certainly take of this going forward.
> 
> >As you have seen on that thread, a couple of proposals have been
> >made for how to fix this without affecting other platforms (the HOB
> >variant[1] and the separate .inf[2] variant). I will keep chasing
> >on that >occasionally, but please also contribute to that
> >conversation yourself.
> 
> Pankaj would be responding to this thread and make changes
> accordingly. Please allow us to pursue this patchset as a separate
> thread. We need the base patches to be merged asap so that we can
> submit patches for LX2160A and LS1046A. We have urgent releases
> planned for these platforms.

I (intimately) understand the situation you're in, but we cannot
compromise normal development process of the upstream project due to
project plans of individual contributors.

My suggestion is that if this is holding your release back, then drop
the console changes completely from this set and do your release based
on upstream plus specifically those patches cherry-picked on top.
I would not (for example) mind those patches being sent out to the
list with a --subject-prefix of "DO NOT MERGE edk2-platforms" instead
of "PATCH edk2-platforms". While staying close to upstream is both
laudable and more efficient, productising based *only* on upstream is
... shall we say extremely optimistic.

If you prepare to do the cherry-pick solution, then you can very
quickly revert that and use upstream only if the full solution gets
there in time.

/
    Leif