Dear Dirk,
In message 49F2B6B9.7040300@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