Re: [B.A.T.M.A.N.] RFC: Removing one indirection layer for patches

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 5161 bytes --]

On Wednesday 05 December 2012 00:01:26 Antonio Quartulli wrote:
[...]
> > 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.

Yes, but adding extra time isn't it. Testing and debugging would be an 
important part.. but is it done in a way that it pays for the extra pain when 
David is doing his monkey dance?
 
> > 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.

I am not 100% sure about the mac80211, but it looks at least like it. But "let 
them wait for some days" is still a good idea.

> > 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 :)

No, month like in "30 days of night". Lets use an example. Please search for 
"Add the backbone gateway list to debugfs" on the mailing list. It should be 
from 2012-06-14. It will be included in the kernel released in ~1 week. My 
guess is 2012-12-10 (so missed the "beginning of the seventh month" only by 
some days). It was send by you to David on 2012-08-23. So it was 
beginning/middle of the third month.

It was just a random patch. I think I would be able to find better matching 
ones, but it should be understandable that my guess is not so extreme wrong.

> > 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?

No, month like in "twelve of them make a year".

> > 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.

And my anti-thesis is "we don't gain much in this incubation phase, but create 
more problems later on". It worked fine in the past because we didn't know 
what to sent and picked special patches and moved stuff around (i still have 
bad dreams about the gateway stuff).

So, this anti-thesis should give us the opportunity to reassess the current 
strategy to work with patches.

> 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? :)

Definitely, but I think you are the right person to answer whether this 
incubation time helped us or whether it is only a tiny amount of fixes and the 
rest of the fixes came from other things.

We have to keep in mind that we are not living in our own isolated universe, 
but that there are also other persons involved which use the other way of 
getting stuff in the kernel. And from time to time they collide with our stuff 
in master. And don't forget our hellkeeper David, the incontrovertible opinion 
himself.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]