Hi Dirk,
Dirk Behme wrote: > Hi Ben, > > Ben Warren wrote: >> Hi Dirk, >> >> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme >> <dirk.be...@googlemail.com>wrote: >> >>> Dear Jean-Christophe, >>> >>> David Brownell wrote: >>> ... >>>>>> http://lists.denx.de/pipermail/u-boot/2009-April/050802.html >>>>> the Patch series and this has been apply in the u-boot-arm/next >>>> I see that branch now exists ... thanks! :) >>> .... >>>> Could you clarify the current merge cycle for me, by the way? >>>> I know u-boot has switched to 2009.{01,03,05,...} releases, >>>> which is a big win from where I sit!, with "rc" tags. >>>> >>>> What I'm unclear on is what gets merged for 2009.05 versus >>>> later. Are these "next" branches for the '05 release (which >>>> hasn't yet hit rc1)? Or for '07 instead? >>> Yes, I have the same questions. I already tried to ask similar, but >>> didn't get an answer. >>> >>> http://lists.denx.de/pipermail/u-boot/2009-April/051111.html >>> >>> Maybe my wording was a little unclear? >>> >>> Dirk >>> >>> Btw.: Now that -next exists, I can't find patch linked above in it, >>> though :( >>> >> >> My approach is that once the merge window closes, new patches that >> are not >> bug fixes go into 'next', which is for the release after the current >> one (in >> this case 07). When the merge window opens again, next goes to >> master and >> the fun starts again. > > Yes, this is my basic understanding, too. > > But there are always these ugly details ;) > > - What's about patches that remove dead code, unused macros etc. IMHO > they can be handled like bug fixes and applied while rc? > I agree that cleanup patches should have more flexibility. > - What's about patches that are sent while open merge window or > before, but need some update cycles and are finalized while rc? > My policy is to look at the timestamp of the first revision. If it's during the merge window, follow-on versions are OK too. > - What about patches which are sent immediately after merge window > closed (hours - 1 or 2 days)? I already heard something like 'no > problem if it comes some hours later, if it is fine then I will still > apply it'. > Well, since communication about the window state is rare at best, a good argument can be made for flexibility here. > What I personally find essential for patch submitters is the patch > dealing by custodian. It should be consistent and by this somehow > predictable. This helps patch submitters to get a feeling for 'this > patch has only a chance while merge window is open' or 'it's worth > sending this patch immediately, it will have a chance to be merge now'. > Sure - consistency would be great. Unfortunately every custodian has his own approach and it's a volunteer workforce. Definitely a goal worth pursuing, though. > What confuses me is something like patch A is applied short time after > sent, patch B will be eventually applied later to next, patch C gets > no comments. With A and B doing the same stuff, and maybe C sent > before A. > Yeah, better and quicker feedback is a goal we should all be working towards. Obviously small, trivial patches are easier to review than new drivers, and so are typically applied more quickly. >> I can't say for sure if this is how all branches are >> handled, though. > > Let's wait for Jean-Christophe opinion. > > Best regards > > Dirk > regards, Ben _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot