
On 6/22/19 4:55 PM, Simon Glass wrote:
Hi Tom,
On Tue, 11 Jun 2019 at 02:33, Tom Rini trini@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.