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

["Eric Bénard" <eric@eukrea.com>]

Le Wed, 10 Apr 2013 13:38:16 -0300,
Otavio Salvador <otavio@ossystems.com.br> a écrit :

> On Wed, Apr 10, 2013 at 1:10 PM, Eric Bénard <eric@eukrea.com> wrote:
> > Le Wed, 10 Apr 2013 13:02:25 -0300,
> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >
> >> On Wed, Apr 10, 2013 at 12:52 PM, Eric Bénard <eric@eukrea.com> wrote:
> >> > Le Wed, 10 Apr 2013 12:13:48 -0300,
> >> > Otavio Salvador <otavio@ossystems.com.br> a écrit :
> >> >> On Wed, Apr 10, 2013 at 10:57 AM, Eric Bénard <eric@eukrea.com> wrote:
> >> >> > Le Wed, 10 Apr 2013 10:48:31 -0300,
> >> >> > Otavio Salvador <otavio@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 ?
> 
> Sure not; and this wasn't the case.
> 
so I don't understand the point but that's not a big issue ;-)

> > 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.
> 
> This is how I work in my local tree. I have several local branches
> with many work in progress patches not yet ready for sending.
> 
I was talking about accessible topic branches which would contain the
patchset you think is ready for submission but that you want others
to give a try. 
To be clear if your problem is to handle queue of patches on the ML :
you send the patches to the ML and put them on a topic branch based on
master, so that the patches are easy to integrate to master once
reviewed and other peoples can also easily test by just checking out
this topic branch.

> >> 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 ?
> 
> Because than we'd have to no time to fix regressions in the release.
> If you check, yesterday a build failure has been fixed for Wandboard
> for example.
> 

> If we add 2013.04 when it is released we have no time to fix any
> remaining issue before final release next week.
> 
then maybe that means that 2013.04 was not the right version for this
release as it's expected to be stable on the 14 when OE-Core 1.4 is
scheduled for the 26 which gives very little time to make serious tests.
Usually a release means a freeze date and after this date no major
version change only stabilization and bug fixes.

Eric