[meta-freescale] [meta-fsl-arm-extra][PATCH v2 6/8] u-boot-imx: Remove Wandboard patch as it is not supported by mainline

[Eric Bénard]

Le Wed, 10 Apr 2013 13:02:25 -0300,
Otavio Salvador <otavio at ossystems.com.br> a écrit :

> On Wed, Apr 10, 2013 at 12:52 PM, Eric Bénard <eric at eukrea.com> wrote:
> > Le Wed, 10 Apr 2013 12:13:48 -0300,
> > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> >> On Wed, Apr 10, 2013 at 10:57 AM, Eric Bénard <eric at eukrea.com> wrote:
> >> > Le Wed, 10 Apr 2013 10:48:31 -0300,
> >> > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> >> >> 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.
> 
> 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.
> 
Would you have prefered to commit them on the flow before the good and
working solution was found ? 

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.
> 
> > 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.
> 
> 
> >> 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.
> 
> It depends on many things and we can also change it again in another
> patch for fixing it better.
> 
> So I think we shouldn't hold for too long as it makes life harder for
> people merging and testing these stuff.
> 
> > 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.
> 
> The U-Boot will be released very soon and it will be the stable branch.
> 
then why hurry and not wait for the release ?

Eric