From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philipp Tomsich Date: Tue, 13 Nov 2018 14:30:05 +0100 Subject: [U-Boot] [ANN] U-Boot v2018.11 delayed a day In-Reply-To: <20181113011247.GV11247@bill-the-cat> References: <20181112214016.GS11247@bill-the-cat> <8668e5b6-00a7-0ebb-8910-b9dd8dabf81b@gmail.com> <20181112222515.GU11247@bill-the-cat> <64cad1b6-99d6-f692-4b9f-aced8fd86fb5@gmail.com> <20181113011247.GV11247@bill-the-cat> Message-ID: <2408D809-B5EE-4093-8C15-B7B54F80EE2E@theobroma-systems.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de > On 13.11.2018, at 02:12, Tom Rini wrote: >=20 > 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, >>>>>=20 >>>>> Since Jagan promise a v2 SPI PR for some build fixes that we should h= ave >>>>> 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! >>>>=20 >>>> Will anyone have any chance to test those fixes to verify they didn't >>>> break anything ? >>>=20 >>> Since they're obvious enough by inspection, I'm not worried about it. >>=20 >> Which patches are those ? >=20 > The ones in question? >=20 >>>> I believe this is yet another manifestation of the problems of the 2 >>>> month release cycle, which I think is too short and stressful. >>>=20 >>> And I believe that's a red herring. All the same I am still considering >>> changes. >>=20 >> 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. >=20 > 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=E2=80=99s a large number of changes going = into the tree after rc1 and rc2: this makes is hard to maintain a next-tree as a cus= todian and merge that early. I have been holding off on changes post-rc1 for qual= ity 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 coul= d keep the master in a testing-state from rc1 (or rc2) on and still push new chang= es and features into a common next tree that might also get early test exposur= e.