[U-Boot] [PATCH] eeprom: fix eeprom write procedure

[Tom Rini]

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'.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151215/e913a187/attachment.sig>