On 6/22/19 4:55 PM, Simon Glass wrote: > Hi Tom, > > On Tue, 11 Jun 2019 at 02:33, Tom Rini <tr...@konsulko.com> 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. >> >> 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 2 months. I find the current release disappears into a > black hole for a about a month, and patches sit on the list for what > seems like eternity. I have the option of doing a -next branch but it > seems that very few do this. > > I'd like to better understand the benefits of the 3-month timeline.
Stability, with the 2 months cycle, there was no time to stabilize the release and fix bugs, everyone was just cannonfodding patches upstream all the time. The result was always a release which wasn't quite well done, had rough edges, unfixed bugs and it wasn't something which you could deploy. Now we have 1 month window where we only accept bugfixes and where things slow down. This removes some stress from the maintainers too. And that lets us take a step back and think about the bigger project questions, rather than just dealing with the onslaught of patches. -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
