From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 96618E014BC for ; Wed, 10 Apr 2013 09:10:27 -0700 (PDT) Received: from e6520eb (pac33-2-82-240-38-71.fbx.proxad.net [82.240.38.71]) (Authenticated sender: eukrea) by smtp2-g21.free.fr (Postfix) with ESMTPSA id CF95C4B00C6; Wed, 10 Apr 2013 18:10:18 +0200 (CEST) Date: Wed, 10 Apr 2013 18:10:17 +0200 From: Eric =?UTF-8?B?QsOpbmFyZA==?= To: Otavio Salvador Message-ID: <20130410181017.588bfa28@e6520eb> In-Reply-To: References: <1365535321-27350-1-git-send-email-otavio@ossystems.com.br> <1365535321-27350-8-git-send-email-otavio@ossystems.com.br> <5164D31A.7030108@gmail.com> <20130410141524.334be50f@e6520eb> <20130410150644.72e8765c@e6520eb> <20130410153854.0ec16740@e6520eb> <20130410155739.3ddc3ebf@e6520eb> <20130410175209.78947ce6@e6520eb> Organization: =?UTF-8?B?RXVrcsOpYQ==?= Electromatique X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.13; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Cc: meta-freescale Mailing List Subject: Re: [meta-fsl-arm-extra][PATCH v2 6/8] u-boot-imx: Remove Wandboard patch as it is not supported by mainline X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:10:30 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le Wed, 10 Apr 2013 13:02:25 -0300, Otavio Salvador a =C3=A9crit : > On Wed, Apr 10, 2013 at 12:52 PM, Eric B=C3=A9nard wrot= e: > > Le Wed, 10 Apr 2013 12:13:48 -0300, > > Otavio Salvador a =C3=A9crit : > >> On Wed, Apr 10, 2013 at 10:57 AM, Eric B=C3=A9nard w= rote: > >> > Le Wed, 10 Apr 2013 10:48:31 -0300, > >> > Otavio Salvador a =C3=A9crit : > >> >> You are welcome to review the patches and test; I just cannot keep > >> >> holding patches for so long as it is a nightmare to manage a huge > >> >> queue of patches. Specially when they are tested and need more wider > >> >> test. > >> > > >> > less then 24 hours between sending the match on the ML and comitting > >> > them doesn't allow any serious testing by the ML readers. > >> > >> Agreed. It was indeed less than 24 hours. > >> > >> Next time I will give 48 hours for huge or complex patchsets; I just > > > > 48h is very short for people to test such big changes especially for > > those who have other occupations than meta-fsl-arm. >=20 > The biggest problem here is we may have a bottleneck of queued > patches; one exemple was the GPU patches that were worked for very > long time until we found a good and working solution but it was a > nightmare for me to keep all the versions working and testing with and > without it. >=20 Would you have prefered to commit them on the flow before the good and working solution was found ?=20 Maybe you need to setup a sandbox branch which can be rebased instead of pushing directly to master or topic branches for work in progress. > A huge queue of patches also makes the handle of all this harder for > as you're not the only one which work in other things than > meta-fsl-arm. >=20 > > Most versions of software in meta-fsl-* don't change very fast so > > allowing something like a week for peoples to test doesn't seems a big > > issue. >=20 >=20 > >> don't see a reason to wait 24 hours for trivial bug fixes however I > >> agree a U-Boot change needs more time and will follow this rule next > >> time. > >> > > > > because even a trivial bugfix can contain an error or someone else may > > have ideas for a better fix so review is important unless. >=20 > It depends on many things and we can also change it again in another > patch for fixing it better. >=20 > So I think we shouldn't hold for too long as it makes life harder for > people merging and testing these stuff. >=20 > > And in the present case, you default many boards to a bootloader > > version which is not a stable one which IMHO is a not a good thing. >=20 > The U-Boot will be released very soon and it will be the stable branch. >=20 then why hurry and not wait for the release ? Eric