Hello Sven, list,
Thank you for your effort in writing this email
On Tue, Dec 04, 2012 at 10:50:08PM +0100, Sven Eckelmann wrote: [...]
So, what happens when something gets rejected or has to be reworked? Yes, some people have to run around and do a lot of magic. These things will end up in next (because this is were Antonio is working when he sends patches to David) and all the new stuff in master has to be rebased later on top of the new things in next [did I just loose most of my audience or is this snoring coming out of my PC?].
no, not yet :) maybe your fan is running too much.
[...]
The big question is: Is this extra waiting time for new feature patches really useful in the current situation and does batman-adv benefit from it in a special/irreplaceable way?
the added value I see in having this extra time is the that we can spend some days in testing it, running it on nodes and trying to find bugs. But, to be honest, I don't know if out there we have people really doing this on a daily/weekly basis.
My personal observation is rather negative. Most problems are detected by people using the release and by people checking the patches (on the b.a.t.m.a.n. mailing list and on netdev... this includes "i am really really angry about what you did" David). But of course, my impressions could be slightly biased. I think Antonio can give more insights about it because he has to squash all the stuff together.
well, if I got you correctly the problem here is "only" about time: with the current method we "wait" more time before sending patches upstream, while in your suggestion we will immediately (well we could still wait some days in order to let the build tests do their optimum job and double check the code - because yes, I re-read each and every patch before sending them to David..strange eh? :D).
So, you would like a mac80211 like process, I think.
Here just a calculation for a new feature patch:
- Send to b.a.t.m.a.n@lists.open-mesh.org at the beginning of the first month
- accepted by Marek in the middle of the first month (had to be resent or so)
- will be part of next in the middle of the third month
- will be sent to David in the middle of the third month (uh, fast Antonio)
- will be send to Linus by David at the the beginning of the fifth month
- will be released as a separate kernel module in the middle of the fifth month
- will be released in a kernel at the beginning of the seventh month
you meant weeks here? It sounds like a birth :)
Antonio already showed that he can handle adhoc pull requests very well. Therefore, the idea would be to remove the two month extra waiting time.
I hope you still meant weeks here..or am I missing something?
Here are just two random branch names:
- next - new patches are excepted here - so it is something like net-next for batman-adv. Antonio will gather some patches and then sent them to David. Davids reaction will come heavy and hard... but the effort for an reaction is reduced.
- master - bugfix gathering place. So it is like net for batman-adv. Patches will end up really fast in Linus' tree.
To be honest I thought the same some time ago, but I think there was a good reason to have it like it is now. I exposed my thoughts to Marek (? I can't really remember) and he explained me why it was nice to have a pre-incubation.
But I would still say it is a good idea to create releases from next because more people will test it and therefore it is easier to get bugfixes to Linus' instead through the stable queue. .1 releases from master can still be created when necessary.
So, why bringing this up now? We currently have 12 Patches in master and Linux 3.7 will be released soon. So switching the patch strategy will not break loose hell. And as a nice side effect: it is not too tragic when C.A.T.W.O.M.A.N. is not merged right now.
But what would it mean for the next release? Hm, the next release would be created from next, but then we propably have to use some tricks. Right now master is too far ahead because it has the role of next+1. We would have to move the patches to next (simple merge) and reset master to the release.
Further .0 releases would just be made on next and then master merges the release. Additional fixes in master can "simply" be merged in next.
Let the fight begin...
Ok, as I stated before, this mac80211 approach is fine with me. I like the idea of a direct flow that goes to upstream without a waiting time in our pre-incubation repository.
However, I'd like to hear about why we have this strategy now from the people that decided this (Sven maybe you were involved in the initial decision too?), because if it is such, I think there is an advantage somewhere. So before losing this advantage just because "now" we think it is better way B, I'd rather prefer hear all the other people opinions.
The advantage I see is that, if we make a mistake and we send a fix, we can still merge the original patch and fix together before sending it to David. I think this give us a not negligible margin of error. But maybe we became good enough to get rid of this margin? :)
Cheers,