Hi Dirk,
Dirk Behme wrote:
Hi Ben,
Ben Warren wrote:
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme dirk.behme@googlemail.comwrote:
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