> On 13.11.2018, at 02:12, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Nov 13, 2018 at 01:03:41AM +0100, Marek Vasut wrote: >> On 11/12/2018 11:25 PM, Tom Rini wrote: >>> On Mon, Nov 12, 2018 at 11:13:29PM +0100, Marek Vasut wrote: >>>> On 11/12/2018 10:40 PM, Tom Rini wrote: >>>>> Hey all, >>>>> >>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should have >>>>> in the release and I believe didn't get them out before the end of his >>>>> day, I'm letting everyone know now to expect the release tomorrow >>>>> instead, thanks! >>>> >>>> Will anyone have any chance to test those fixes to verify they didn't >>>> break anything ? >>> >>> Since they're obvious enough by inspection, I'm not worried about it. >> >> Which patches are those ? > > The ones in question? > >>>> I believe this is yet another manifestation of the problems of the 2 >>>> month release cycle, which I think is too short and stressful. >>> >>> And I believe that's a red herring. All the same I am still considering >>> changes. >> >> I'd really like to know how do other maintainers feel about this 2 month >> release cycle vs. for example 3 month like Linux does. I think the later >> is about right, 2 months is too short. > > Yes, I've asked before and there's a few people in the same camp as you, > and there's a few people who like 2 months, and there's a large number > of no strong opinions. That's why I'm still thinking about changing > things again.
My biggest concern is that there’s a large number of changes going into the tree after rc1 and rc2: this makes is hard to maintain a next-tree as a custodian and merge that early. I have been holding off on changes post-rc1 for quality reasons (so people have sufficient time to test), but am not maintaining a next tree which makes things appear slow in being merged. Possibly a next or staging tree on your level might resolve this: this could keep the master in a testing-state from rc1 (or rc2) on and still push new changes and features into a common next tree that might also get early test exposure. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot