[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for 4.19] CHANGELOG.md: Finalize changes in 4.19 release cycle



On Mon, 2024-07-29 at 10:11 +0200, Jan Beulich wrote:
> On 29.07.2024 09:31, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> 
> Since no-one else cared to reply so far, I will (I tried to avoid
> doing so,
> because - I'm sorry for that - feedback is mostly negative, in part
> following
> what I said for some 4.18 entries last time already, iirc):
Any feedback is good!

> 
> > --- a/CHANGELOG.md
> > +++ b/CHANGELOG.md
> > @@ -15,6 +15,17 @@ The format is based on [Keep a
> > Changelog](https://keepachangelog.com/en/1.0.0/)
> >     - Reduce IOMMU setup time for hardware domain.
> >     - Allow HVM/PVH domains to map foreign pages.
> >     - Declare PVH dom0 supported with caveats.
> > + - On Arm:
> > +   - Reworking the logic so all the MMU-off code is now self-
> > contained for
> > +     secondary boot CPUs on arm64.
> 
> This is an implementation detail aiui nothing people using Xen would
> actually
> stumble across or notice. Imo such doesn't belong here. Same goes for
> the
> entire PPC part of this hunk further down.
> 
> > +   - Code symbol annotations and MISRA compliance improvements.
> 
> This isn't Arm-specific, is it?
Agree, this is not Arm-specific, so I will move it to "Changed".

> 
> > +   - Addressing issues of the static shared memory feature.
> 
> Along the lines of the above, I don't think individual features' bug
> fixes
> want/need mentioning here.
> 
> > @@ -23,6 +34,11 @@ The format is based on [Keep a
> > Changelog](https://keepachangelog.com/en/1.0.0/)
> >     using a standalone library implementation.
> >   - xenalyze no longer requires `--svm-mode` when analyzing traces
> >     generated on AMD CPUs
> > + - CI updates:
> > +   - Minimum fixes to rebuild the containers, following the
> > HEREDOC problems.
> > +   - Rebuild containers to have testing with up-to-date LTS
> > distros.
> > +   - Few build system checks, and strip the obsolete contents of
> > +     the build containers.
> 
> This again doesn't concern people using Xen, does it?
What about people who are building Xen themselves? This part of the
changelog informs them that we have verified Xen builds with the latest
up-to-date LTS.

> 
> > @@ -31,6 +47,14 @@ The format is based on [Keep a
> > Changelog](https://keepachangelog.com/en/1.0.0/)
> >   - Add a new 9pfs backend running as a daemon in dom0. First user
> > is
> >     Xenstore-stubdom now being able to support full Xenstore trace
> > capability.
> >   - libxl support for backendtype=tap with tapback.
> > + - On Arm:
> > +   - FF-A notification support.
> > +   - Introduction of dynamic node programming using overlay dtbo.
> 
> This is fine to have. I wonder though if the per-arch sections
> wouldn't
> better sit next to each other (all at the top or all at the bottom).
I didn't get you here. Everything in "### Added" is sorted per-arch.

> 
> > + - On PPC:
> > +   - Basic exception handler implementation.
> > + - On RISCV:
> > +   - Identity mapping implementation.
> > +   - Introduction of architecture-specific headers.
> 
> These again don't concern people using Xen, do they?
Well, I agree that PPC/RISCV is far away from being used but still it
shows that progress is going on.

Do we have the document which tell what should be in CHANGELOG and what
shouldn't?

~ Oleksii



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.