From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/2] tools: mkenvimage: Fixes for reading from pipes
Date: Mon, 1 Jul 2019 09:23:26 -0400 [thread overview]
Message-ID: <20190701132326.GH9388@bill-the-cat> (raw)
In-Reply-To: <20190701102246.2ceec495@donnerap.cambridge.arm.com>
On Mon, Jul 01, 2019 at 10:22:46AM +0100, Andre Przywara wrote:
> On Sun, 30 Jun 2019 10:40:44 -0400
> Tom Rini <trini@konsulko.com> wrote:
>
> Hi Tom,
>
> > On Sun, Jun 30, 2019 at 02:44:59AM +0100, Andre Przywara wrote:
> >
> > > This fixes two issues I had when trying to create an envimage from a
> > > more complex pipe:
> > > - The read process stops when the read(2) syscall returns less bytes
> > > than requested.
> > > - Specifying an input filename expects this to be a regular file.
> > >
> > > See the respective commit messages for more details.
> > >
> > > Thanks!
> > > Andre
> > >
> > > Andre Przywara (2):
> > > tools: mkenvimage: Fix reading from slow pipe
> > > tools: mkenvimage: Always consider non-regular files
> > >
> > > tools/mkenvimage.c | 71 ++++++++++++++++--------------------------------------
> > > 1 file changed, 21 insertions(+), 50 deletions(-)
> >
> > These all look fine but in the interest of avoiding unintended
> > consequences I'm going to pull these in after v2019.07 as they're
> > long-standing bugs rather than regressions being fixed, thanks!
>
> Thanks, that was my intention anyway.
>
> So is the development model now "only send new changes/features in the
> merge window"? I was suspecting that with this new long stabilisation
> phase we prepare patches outside of the merge window?
> Or was the "Fixes ..." in the subject line giving the wrong impression
> of my intention?
New changes / features should still be posted when they're ready for
public review, to get the most possible review done to them. I just
figured that since this was a series that was fixing a problem I should
give it a look and since I could see an argument in favor of merging
them now, say why I wasn't.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190701/1d9b6087/attachment.sig>
prev parent reply other threads:[~2019-07-01 13:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-30 1:44 [U-Boot] [PATCH 0/2] tools: mkenvimage: Fixes for reading from pipes Andre Przywara
2019-06-30 1:45 ` [U-Boot] [PATCH 1/2] tools: mkenvimage: Fix reading from slow pipe Andre Przywara
2019-07-01 6:31 ` Alexander Dahl
2019-07-18 23:57 ` Tom Rini
2019-06-30 1:45 ` [U-Boot] [PATCH 2/2] tools: mkenvimage: Always consider non-regular files Andre Przywara
2019-07-18 23:57 ` Tom Rini
2019-06-30 14:40 ` [U-Boot] [PATCH 0/2] tools: mkenvimage: Fixes for reading from pipes Tom Rini
2019-07-01 9:22 ` Andre Przywara
2019-07-01 13:23 ` Tom Rini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190701132326.GH9388@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.