On Tue, Dec 15, 2015 at 12:09:21PM +0000, Alexey Brodkin wrote:
[snip]
But jokes aside I'm a bit confused with development cycle of U-Boot. I mean here we're free to push quite important changes at any point even if tomorrow Tom is cutting the next release. RCs are out of the question at all.
Well, the rule of thumb is to get changes out by "around" rc1. I did -rc1 on the 16th, Marek posted this series on the 10th and I merged it on the 21st. So all things considered, I know I've done worse merges.
But the topic also does come up more often than it should, so something in the balance isn't right.
I have to confess I do it myself from time to time just because it's so easy and nobody cares. But that really makes me worry because I cannot afford running U-Boot on every board I support on each and every commit. Which in turn means there's a possibility in final release some of my boards will be broken to some extent.
Well, that's just it. I put a good level of discretion to the various area custodians to take what they're comfortable with, given what they can test and how close to the release things are.
That said I really like Linux development procedure when merge window is open just for a week or so and then only regression fixes are accepted during RC cycles.
Still that very-very formal approach could be a bit of overkill for us here. But there's another good example - Buildroot.
In the same way as we do it they accept patches right in master branch but only until the first RC. From RC1 on only fixes go in master, everything else goes to "next" branch. And "next" gets merged in master right after release.
Again I'm not following U-boot mailing list closely so I might be missing similar ongoing discussion so please be lenient to that my rant :)
Well, what I don't like about 'next' is people are either going to be testing 'next' (And not what's going to be released soon) or they're testing master (and we're just delaying problems being seen and mildly more annoying to bisect back to).
At ELC-E we had talked about moving to a nominal 2 month rather than 3 month (meaning it's released when it's ready, not a hard calendar deadline) release schedule. That would remove some of the pressure of 'take $X so it's not seemed to be forgotten between releases'.