Dear Dirk, In message <49f2b6b9.7040...@googlemail.com> you wrote: > > > 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.
Mine, too. Note however that I will not always and not automatically and not exactly at the end of the merge window create a next branch, but I'm in a somewhat specialposition anyway. > 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? They can, if the custodian accepts it, and.or if there is consensus on the ML. > - What's about patches that are sent while open merge window or > before, but need some update cycles and are finalized while rc? These should go in. People who put a lot of effort in their planning should not suffer from the fact that a custodian is slow on answering or reviewing their patches. Everything that has been sent to the list before the end of the MW should go in. > - 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'. Patch acceptance is not as critical as a financial transaction, or such. So if there is a slight delay, the custodian is free to turn a blind eye and accept it anyway. The idea of the development process is to make it foreseeable and plannable, but not to become a PITA or to slow down development. It makes much more sense if an engineer spends another day on testing and cleanup and submits the patch a couple of hours late, instead of submitting a green patch which will waste efforts from several prople during several rounds of review and reposts. > 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'. But this should be clear: if sent while the merge indow is open, new stuff can go in. If the MW is closed, new stuff may go into next (if the respective custodian runs a next branch), otherwise it has to wait until the next MW. Bug fixes can go in any time. > 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. I agree that this is not nice. In any case, there should be some comment from the respective custodian which makes *clear* what the patch state is. Even a "I have no time now, will look into it later" is better than nothing. Also, if there are remarks to a patch, these should leave no doubt if they were just comments and the patch will be accepted anyway, or if the patch should be reworked/resubmitted, or if the patch was rejected without chance to be included at all. > > I can't say for sure if this is how all branches are > > handled, though. > > Let's wait for Jean-Christophe opinion. Well, his opinion is one thing. But I think we can also expect from Jean-Christophe as ARM custodian that he delivers clear and under- standable feedback to all patch submitters. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Make it right before you make it faster. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
