All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Date: Mon, 24 Jun 2019 19:10:01 +0200	[thread overview]
Message-ID: <d078673e-e019-74ca-1353-d60e7234c769@denx.de> (raw)
In-Reply-To: <CAPnjgZ3-MDmu3wnm9-eMTkhMN=X+yNV9rC4xBMWO1UHkKz4cVg@mail.gmail.com>

On 6/24/19 3:56 PM, Simon Glass wrote:
> Hi Andreas,,
> 
> On Sat, 22 Jun 2019 at 20:49, Andreas Färber <afaerber@suse.de> wrote:
>>
>> Hi Simon,
>>
>> Am 22.06.19 um 21:14 schrieb Simon Glass:
>>> On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 22.06.19 um 20:15 schrieb Simon Glass:
>>>>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber@suse.de> wrote:
>>>>>> Am 22.06.19 um 16:55 schrieb Simon Glass:
>>>>>>> I'd like to better understand the benefits of the 3-month timeline.
>>>>>>
>>>>>> It takes time to learn about a release, package and build it, test it on
>>>>>> various hardware, investigate and report errors, wait for feedback and
>>>>>> fixes, rinse and repeat with the next -rc. Many people don't do this as
>>>>>> their main job.
>>>>>>
>>>>>> If we shorten the release cycle, newer boards will get out faster (which
>>>>>> is good) but the overall quality of boards not actively worked on
>>>>>> (because they were working good enough before) will decay, which is bad.
>>>>>> The only way to counteract that would be to automatically test on real
>>>>>> hardware rather than just building, and doing that for all these masses
>>>>>> of boards seems unrealistic.
>>>>>
>>>>> Here I think you are talking about distributions. But why not just
>>>>> take every second release?
>>>>
>>>> You're missing my point: What good is it to do a release when you
>>>> yourself consider it of such poor quality that you advise others not to
>>>> take it?
>>>
>>> Who said that?
>>
>> You, quoted above. In response to my concerns about decreasing quality
>> you suggested to take only every second release. That doesn't improve
>> the quality of either. It implies that one may have such bad quality
>> that people should skip it and yet does nothing to improve the next.
> 
> Actually I did not say that I consider the release of such poor
> quality. Nor did I advise others to take it. I suspect this is a
> misunderstanding of "But why not just take every second release?".
> 
> My point was that if people don't have time to test every release,
> then just put in the time to test every second release.

So what about be the point of releasing the untested intermediate
release at all ? I'm sure people can just grab u-boot/master or -rc2
just fine.

[...]

-- 
Best regards,
Marek Vasut

  reply	other threads:[~2019-06-24 17:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-11  1:31 [U-Boot] [ANN] U-Boot v2019.07-rc4 released Tom Rini
2019-06-11  2:56 ` [U-Boot] [U-Boot-Board-Maintainers] " Marek Vasut
2019-06-11 11:15   ` Tom Rini
2019-06-11 13:39     ` Marek Vasut
2019-06-11  5:38 ` Lukasz Majewski
2019-06-16 17:36 ` [U-Boot] Poplar broken in U-Boot v2019.07-rc4 Andreas Färber
2019-06-17  2:16   ` Shawn Guo
2019-06-17  2:19     ` Bin Meng
2019-06-17  2:31       ` Shawn Guo
2019-06-22 14:55 ` [U-Boot] [ANN] U-Boot v2019.07-rc4 released Simon Glass
2019-06-22 15:08   ` [U-Boot] [U-Boot-Custodians] " Marek Vasut
2019-06-22 15:10   ` [U-Boot] [U-Boot-Board-Maintainers] " Andreas Färber
2019-06-22 18:15     ` Simon Glass
2019-06-22 19:08       ` Andreas Färber
2019-06-22 19:14         ` Simon Glass
2019-06-22 19:49           ` Andreas Färber
2019-06-24 13:56             ` Simon Glass
2019-06-24 17:10               ` Marek Vasut [this message]
2019-06-25  0:10                 ` [U-Boot] [U-Boot-Custodians] " Simon Glass
2019-06-22 19:12       ` Heinrich Schuchardt
2019-06-22 19:43         ` Marek Vasut
2019-06-24 15:29           ` Tom Rini
2019-06-25 11:10             ` [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] " Neil Armstrong
2019-06-25 12:04               ` Tom Rini
2019-06-30 10:34                 ` Matwey V. Kornilov
2019-07-01  7:23                   ` Neil Armstrong
2019-07-02 16:04           ` [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] " Troy Benjegerdes
2019-07-02 17:03             ` Marek Vasut
2019-07-03 15:59             ` Simon Glass
2019-07-03 16:04               ` [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] " Tom Rini
2019-07-03 16:22                 ` Troy Benjegerdes
2019-07-03 19:34                   ` Heinrich Schuchardt
2019-06-25  3:51         ` [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] " Heiko Schocher
2019-06-30 10:32         ` Matwey V. Kornilov

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=d078673e-e019-74ca-1353-d60e7234c769@denx.de \
    --to=marex@denx.de \
    --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.