Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Andreas,, On Sat, 22 Jun 2019 at 20:49, Andreas Färber wrote: > > Hi Simon, > > Am 22.06.19 um 21:14 schrieb Simon Glass: > > On Sat, 22 Jun 2019 at 20:08, Andreas Färber wrote: > >> Am 22.06.19 um 20:15 schrieb Simon Glass: > >>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber 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. I am actually not sure how much a bit of extra time helps with stability. Have the last two releases been more reliable on hardware, since people have found time to test them using the 9-week -rc phases, whereas the previous 6-week one did not? > > > Your point, I thought, was that people didn't have time to test it? > > Not quite, I was talking about the full build-test-report-fix cycle > taking its time. Bugs in one -rc don't necessarily get detected and > fixed in time for the next -rc. That doesn't change unless the distance between rc's increases. But I think your point is that there are more -rc releases so more time to find and fix things. > > And I fail to see how your suggestion of skipping releases gives them > more time to test before the U-Boot release. That would rather be an > argument for slowing down the U-Boot release cycle beyond 3 months > (which I'm not asking). It would mean testing only every second release, which halves the time you spend testing, a significant reduction in load. Just need to schedule testing time over (say) 6 week, 3 times a year instead of 6 times. I think an automated test setup is the best way to do this. Marek asks who would run it? Perhaps people who have an interest in each board and want to spend less time on manual testing? We already have the technology to do this, with pytest and tbot. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Simon, Am 22.06.19 um 21:14 schrieb Simon Glass: > On Sat, 22 Jun 2019 at 20:08, Andreas Färber wrote: >> Am 22.06.19 um 20:15 schrieb Simon Glass: >>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber 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. > Your point, I thought, was that people didn't have time to test it? Not quite, I was talking about the full build-test-report-fix cycle taking its time. Bugs in one -rc don't necessarily get detected and fixed in time for the next -rc. And I fail to see how your suggestion of skipping releases gives them more time to test before the U-Boot release. That would rather be an argument for slowing down the U-Boot release cycle beyond 3 months (which I'm not asking). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Andreas, On Sat, 22 Jun 2019 at 20:08, Andreas Färber wrote: > > Hi, > > Am 22.06.19 um 20:15 schrieb Simon Glass: > > On Sat, 22 Jun 2019 at 16:10, Andreas Färber 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? Your point, I thought, was that people didn't have time to test it? > > That has nothing per-se to do with who uses that release and whether you > build it in OBS or locally. > > > I have certain had the experience of getting a board our of the > > cupboard and finding that the latest U-Boot doesn't work, nor the one > > before, nor the three before that. > > > > Are we actually seeing an improvement in regressions? > > I don't understand that question. The proposal, as I understood it, is > to shorten the release cycle by one month, doing six instead of four > releases. How could there be an improvement by leaving it as it is? My > fear is that the change will make it _worse_, i.e. no improvement but > rather risk of more regressions by switching to _two_ months. > > In this very same -rc4 thread I reported one such regression, and > luckily a patch was quickly prepared to address it. It's not yet merged > despite tested - review also takes time. > > > I feel that > > testing is the only way to get that. > > Agreed. And my point was that testing takes time. Increasing the release > frequency shortens the time for testing of each release. > > > Perhaps we should select a small subset of boards which do get tested, > > and actually have custodians build/test on those for every rc? > > Many custodians are volunteers. You can't force them to test boards at a > pace you dictate to them. Also, more frequent releases also increase the > chances of a custodian/maintainer being on vacation during a release. > > And a working, say, BeagleBone doesn't make the user of a random other > board any happier. ;-) Another question...how much do people care about the latest and greatest features? Perhaps we should be merging patches frequently, but creating a release branch separate from master? The current process seems very very slow to me. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi, Am 22.06.19 um 20:15 schrieb Simon Glass: > On Sat, 22 Jun 2019 at 16:10, Andreas Färber 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? That has nothing per-se to do with who uses that release and whether you build it in OBS or locally. > I have certain had the experience of getting a board our of the > cupboard and finding that the latest U-Boot doesn't work, nor the one > before, nor the three before that. > > Are we actually seeing an improvement in regressions? I don't understand that question. The proposal, as I understood it, is to shorten the release cycle by one month, doing six instead of four releases. How could there be an improvement by leaving it as it is? My fear is that the change will make it _worse_, i.e. no improvement but rather risk of more regressions by switching to _two_ months. In this very same -rc4 thread I reported one such regression, and luckily a patch was quickly prepared to address it. It's not yet merged despite tested - review also takes time. > I feel that > testing is the only way to get that. Agreed. And my point was that testing takes time. Increasing the release frequency shortens the time for testing of each release. > Perhaps we should select a small subset of boards which do get tested, > and actually have custodians build/test on those for every rc? Many custodians are volunteers. You can't force them to test boards at a pace you dictate to them. Also, more frequent releases also increase the chances of a custodian/maintainer being on vacation during a release. And a working, say, BeagleBone doesn't make the user of a random other board any happier. ;-) Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi, On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: > > Hi Simon, > > 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? I have certain had the experience of getting a board our of the cupboard and finding that the latest U-Boot doesn't work, nor the one before, nor the three before that. Are we actually seeing an improvement in regressions? I feel that testing is the only way to get that. Perhaps we should select a small subset of boards which do get tested, and actually have custodians build/test on those for every rc? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Simon, 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. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
On 6/11/19 1:15 PM, Tom Rini wrote: > On Tue, Jun 11, 2019 at 04:56:24AM +0200, Marek Vasut wrote: >> On 6/11/19 3:31 AM, Tom Rini wrote: >>> Hey all, >>> >>> It's release day and here is v2019.07-rc4. At this point, I know we >>> have some regression fixes for i.MX that are coming, and I'm expecting a >>> fix to the build time failure for tinker-rk3288. >>> >>> To repeat myself about DM migration deadlines, first, let me say again, >>> that DM is not required for SPL. This comes up enough that I want to >>> say it again here. Next, if there is active progress on converting >>> things, we'll keep from pulling the code out. This is why for example, >>> we haven't yet pulled out a lot of deprecated SPI code. Some of it is >>> still in progress on being converted, so I need to update the series I >>> posted after the last -rc to remove still less drivers. >>> >>> In terms of a changelog, >>> git log --merges v2019.07-rc3..v2019.07-rc4 >>> continues to improve in quality. If you're sending me a PR, please >>> include a few lines or words in summary and I'll be sure to put it into >>> the merge commit. >> >> Do you have a list of the platforms that are currently in the danger zone ? > > In what way? Uncaught size overflow? No, but I hope a lot of > maintainers take advantage of this new feature so we can catch this > problem and do something about the root cause. DM migration stuff? Yes, DM migration stuff, would be nice to have a list of boards which still generate warnings. > That doesn't cause the board to get dropped but to lose functionality. > It's too late in this cycle for the SPI conversion series now, but the > Freescale/NXP driver was updated, so it's not nearly as many boards as > it looked like before. > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
On Tue, Jun 11, 2019 at 04:56:24AM +0200, Marek Vasut wrote: > On 6/11/19 3:31 AM, Tom Rini wrote: > > Hey all, > > > > It's release day and here is v2019.07-rc4. At this point, I know we > > have some regression fixes for i.MX that are coming, and I'm expecting a > > fix to the build time failure for tinker-rk3288. > > > > To repeat myself about DM migration deadlines, first, let me say again, > > that DM is not required for SPL. This comes up enough that I want to > > say it again here. Next, if there is active progress on converting > > things, we'll keep from pulling the code out. This is why for example, > > we haven't yet pulled out a lot of deprecated SPI code. Some of it is > > still in progress on being converted, so I need to update the series I > > posted after the last -rc to remove still less drivers. > > > > In terms of a changelog, > > git log --merges v2019.07-rc3..v2019.07-rc4 > > continues to improve in quality. If you're sending me a PR, please > > include a few lines or words in summary and I'll be sure to put it into > > the merge commit. > > Do you have a list of the platforms that are currently in the danger zone ? In what way? Uncaught size overflow? No, but I hope a lot of maintainers take advantage of this new feature so we can catch this problem and do something about the root cause. DM migration stuff? That doesn't cause the board to get dropped but to lose functionality. It's too late in this cycle for the SPI conversion series now, but the Freescale/NXP driver was updated, so it's not nearly as many boards as it looked like before. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
Hi Tom, > Hey all, > > It's release day and here is v2019.07-rc4. At this point, I know we > have some regression fixes for i.MX that are coming, and I'm > expecting a fix to the build time failure for tinker-rk3288. > > To repeat myself about DM migration deadlines, first, let me say > again, that DM is not required for SPL. This comes up enough that I > want to say it again here. Next, if there is active progress on > converting things, we'll keep from pulling the code out. This is why > for example, we haven't yet pulled out a lot of deprecated SPI code. > Some of it is still in progress on being converted, so I need to > update the series I posted after the last -rc to remove still less > drivers. > > In terms of a changelog, > git log --merges v2019.07-rc3..v2019.07-rc4 > continues to improve in quality. If you're sending me a PR, please > include a few lines or words in summary and I'll be sure to put it > into the merge commit. > > As I mentioned with -rc3, with this cycle is coming closer to an end, > it's time to decide if we're going to keep this 3 month cycle or go > back to 2 months. I do prefer 3 months cycle. IMHO with 3 months cycle, we do have a time to fix things and adding new code is done in merge window. > After the last release while I did get some > feedback, the overall balance is still in the 3 month bucket. > > I'm planning on doing -rc5 on June 24th with the release scheduled on > July 8th. Thanks all! > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpOIA9TOy9k1.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
On 6/11/19 3:31 AM, Tom Rini wrote: > Hey all, > > It's release day and here is v2019.07-rc4. At this point, I know we > have some regression fixes for i.MX that are coming, and I'm expecting a > fix to the build time failure for tinker-rk3288. > > To repeat myself about DM migration deadlines, first, let me say again, > that DM is not required for SPL. This comes up enough that I want to > say it again here. Next, if there is active progress on converting > things, we'll keep from pulling the code out. This is why for example, > we haven't yet pulled out a lot of deprecated SPI code. Some of it is > still in progress on being converted, so I need to update the series I > posted after the last -rc to remove still less drivers. > > In terms of a changelog, > git log --merges v2019.07-rc3..v2019.07-rc4 > continues to improve in quality. If you're sending me a PR, please > include a few lines or words in summary and I'll be sure to put it into > the merge commit. Do you have a list of the platforms that are currently in the danger zone ? > As I mentioned with -rc3, with this cycle is coming closer to an end, > it's time to decide if we're going to keep this 3 month cycle or go back > to 2 months. After the last release while I did get some feedback, the > overall balance is still in the 3 month bucket. I vote for 3 months, I very much like it. > I'm planning on doing -rc5 on June 24th with the release scheduled on > July 8th. Thanks all! Great -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
