| Message ID | 2db91183-a7de-0c43-2fef-feb3523ed19b@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | zstd decompression for DomU-s + fallout / consolidation | expand |
Jan Beulich writes ("[PATCH v3 00/15] zstd decompression for DomU-s + fallout / consolidation"):
> Only patches 1 and 2 are strictly intended for 4.15, paralleling
> the recent Dom0 side work (and re-using many of the files
> introduced there, for the stubdom build), but ones up to at least
> patch 6 may still want considering (and 4 already has a release
> ack).
Thanks.
> 01: libxenguest: add get_unaligned_le32()
> 02: libxenguest: support zstd compressed kernels
So these two are fine.
> 03: xen/decompress: make helper symbols static
> 04: libxenguest: "standardize" LZO kernel decompression code
> 05: libxenguest: drop redundant decompression declarations
> 06: libxenguest: simplify kernel decompression
I approve of cleanups of course. But:
Which of these cleanups were posted before the LPD ? I'm not
currently aware of any reason for a freeze exception here, so I think
those patches which didn't meet the LPD should wait. Ones which *did*
meet the LPD should be considered on their merits.
If you could direct me to which those are I would be happy to review
them.
> 07: gunzip: drop INIT{,DATA} and STATIC
I release-nacked this because I saw you posted it with this Subject
Subject: [PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC
which made me think you were targeting it for 4.15. If not then fine.
Thanks,
Ian.
On 26.01.2021 13:05, Ian Jackson wrote: > Jan Beulich writes ("[PATCH v3 00/15] zstd decompression for DomU-s + fallout / consolidation"): >> Only patches 1 and 2 are strictly intended for 4.15, paralleling >> the recent Dom0 side work (and re-using many of the files >> introduced there, for the stubdom build), but ones up to at least >> patch 6 may still want considering (and 4 already has a release >> ack). > > Thanks. > >> 01: libxenguest: add get_unaligned_le32() >> 02: libxenguest: support zstd compressed kernels > > So these two are fine. > >> 03: xen/decompress: make helper symbols static >> 04: libxenguest: "standardize" LZO kernel decompression code >> 05: libxenguest: drop redundant decompression declarations >> 06: libxenguest: simplify kernel decompression > > I approve of cleanups of course. But: > > Which of these cleanups were posted before the LPD ? I'm not > currently aware of any reason for a freeze exception here, so I think > those patches which didn't meet the LPD should wait. Ones which *did* > meet the LPD should be considered on their merits. > > If you could direct me to which those are I would be happy to review > them. All of them were posted after that date; only the Dom0 zstd decompression part was ready in time. I view this entire series as a logical extension to the earlier patches though. I'm unsure anyway how new patches in a previously submitted series would be treated in general; so far I've been under the impression that if in doubt the series as a whole would count, not every individual patch. As said (still visible above) I'm not meaning to insist on patches 3 and onwards to be taken. In fact it was you to ask whether patch 3 would possibly want a freeze exception. And you did give patch 4 a release ack already, based on it containing a bug fix. (The latter is true of patch 6 as well, btw.) Are you implying you withdraw that release ack now? While we're at this - how are bug fixes to be treated in this two week window? Do they need a release ack too if they did miss the LPD? I'm asking with specifically "xen/include: compat/xlat.h may change with .config changes" in mind, but there may be others, like Roger's 3-patch series posted today, which I intend to look at rather sooner than later. >> 07: gunzip: drop INIT{,DATA} and STATIC > > I release-nacked this because I saw you posted it with this Subject > Subject: [PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC > which made me think you were targeting it for 4.15. If not then fine. FAOD - indeed it was a mistake of mine and was meant to be 07/15. Jan
Jan Beulich writes ("Re: [PATCH v3 00/15] zstd decompression for DomU-s + fallout / consolidation"):
> On 26.01.2021 13:05, Ian Jackson wrote:
> > I approve of cleanups of course. But:
> >
> > Which of these cleanups were posted before the LPD ? I'm not
> > currently aware of any reason for a freeze exception here, so I think
> > those patches which didn't meet the LPD should wait. Ones which *did*
> > meet the LPD should be considered on their merits.
> >
> > If you could direct me to which those are I would be happy to review
> > them.
>
> All of them were posted after that date; only the Dom0 zstd
> decompression part was ready in time. I view this entire
> series as a logical extension to the earlier patches though.
> I'm unsure anyway how new patches in a previously submitted
> series would be treated in general; so far I've been under
> the impression that if in doubt the series as a whole would
> count, not every individual patch.
I think as a general rule, I don't think "logical extensions" to
things posted before the LPD count. But bugfixes, and smallish
changes necessary to make the rest of a previously-posted series are
OK.
> As said (still visible above) I'm not meaning to insist on
> patches 3 and onwards to be taken. In fact it was you to
> ask whether patch 3 would possibly want a freeze exception.
> And you did give patch 4 a release ack already, based on it
> containing a bug fix. (The latter is true of patch 6 as
> well, btw.) Are you implying you withdraw that release ack
> now?
I'm afraid that I don't keep all this state in my head. I rely on
written materials. Where the written materials in front of me seem
self-sufficient and don't contain unresolved references or things that
are confusing, I rely on what is in front of me being sufficient.
ISTM that the point of a summary mail like yours is to save us going
and rereading all the background each time.
None of the subject lines in your mail mentioned that these were
bugfixes. So I'm afraid I had forgotten that.
I'm not withdrawing my release ack for anything. But whena commit is
being justified for 4.15 because it is (or contains) a bugfix then it
would be really good if the bugfix were mentioned in the summary line.
> While we're at this - how are bug fixes to be treated in
> this two week window? Do they need a release ack too if
> they did miss the LPD?
No.
> I'm asking with specifically
> "xen/include: compat/xlat.h may change with .config
> changes" in mind, but there may be others, like Roger's
> 3-patch series posted today, which I intend to look at
> rather sooner than later.
Things that are just bugfixes do not need a release ack at this stage.
Things that are a mixture should either get a release ack, or be
separated out in which case the bugfix part does not need a release
ack. I am happy to give out (or decline) acks in cases of doubt.
I appreciate your looking at bugfixes as a priority, so thanks.
> >> 07: gunzip: drop INIT{,DATA} and STATIC
> >
> > I release-nacked this because I saw you posted it with this Subject
> > Subject: [PATCH v3 01/15] gunzip: drop INIT{,DATA} and STATIC
> > which made me think you were targeting it for 4.15. If not then fine.
>
> FAOD - indeed it was a mistake of mine and was meant to
> be 07/15.
NP.
I hope this explanation makes some kind of sense and sorry for the
confusion.
Ian.
On 26.01.2021 14:25, Ian Jackson wrote: > I hope this explanation makes some kind of sense and sorry for the > confusion. It does and no, I don't think there was any confusion caused. Some thinks merely needed clarifying, on my end at least. Thanks for doing so. Jan
On 26.01.2021 10:46, Jan Beulich wrote: > Only patches 1 and 2 are strictly intended for 4.15, paralleling > the recent Dom0 side work (and re-using many of the files > introduced there, for the stubdom build), but ones up to at least > patch 6 may still want considering (and 4 already has a release > ack). > > 01: libxenguest: add get_unaligned_le32() > 02: libxenguest: support zstd compressed kernels > 03: xen/decompress: make helper symbols static > 04: libxenguest: "standardize" LZO kernel decompression code > 05: libxenguest: drop redundant decompression declarations > 06: libxenguest: simplify kernel decompression > 07: gunzip: drop INIT{,DATA} and STATIC While these have all gone in, ... > 08: bunzip: replace INIT > 09: unlzo: replace INIT > 10: unlzma: replace INIT > 11: unlz4: replace INIT > 12: unxz: replace INIT{,DATA} and STATIC > 13: unzstd: replace INIT{,DATA} and STATIC > 14: xen/decompress: drop STATIC and INIT > 15: unzstd: make helper symbols static ... may I please ask for an ack (or otherwise) on these? Jan
Only patches 1 and 2 are strictly intended for 4.15, paralleling the recent Dom0 side work (and re-using many of the files introduced there, for the stubdom build), but ones up to at least patch 6 may still want considering (and 4 already has a release ack). 01: libxenguest: add get_unaligned_le32() 02: libxenguest: support zstd compressed kernels 03: xen/decompress: make helper symbols static 04: libxenguest: "standardize" LZO kernel decompression code 05: libxenguest: drop redundant decompression declarations 06: libxenguest: simplify kernel decompression 07: gunzip: drop INIT{,DATA} and STATIC 08: bunzip: replace INIT 09: unlzo: replace INIT 10: unlzma: replace INIT 11: unlz4: replace INIT 12: unxz: replace INIT{,DATA} and STATIC 13: unzstd: replace INIT{,DATA} and STATIC 14: xen/decompress: drop STATIC and INIT 15: unzstd: make helper symbols static Jan