Adrian Filipi-Martin wrote: > On Sat, 18 May 2002, Terry Lambert wrote: > > "Karsten W. Rohrbach" wrote: > > > Brandon D. Valentine([EMAIL PROTECTED])@2002.05.17 14:48:07 +0000: > > > > On Fri, 17 May 2002, Doug White wrote: > > > > >You are welcome to rewrite qmail to use kqueue if you wish :) > > > > > > > > Although if I read the license correctly you hand djb a contract for > > > > your soul and first born child if you do. ;-) > > > > > > if you read the license _correctly_, you'd just distribute a patch, and > > > that's perfectly okay. so, what about to do with your soul and first born > > > child now? ;-) > > > > Spend them maintaining the patch, when DJB fails to integrate the > > patch into the main line source for qmail? > > Sounds like an ideal use of the ports system. The qmail port > already has several patches, so the incremental effort may not be too bad.
>From personal experience, I can tell you that maintaining a large patch set against a source base that does not integrate your changes is exponentially difficult, with the base for the exponent being relative to the rate of change of the code against which the patches were taken. The primary reason NetBSD started (IMO) was to get around exactly this bottleneck with the patchkit system... though I would have to say that there were some control issues involved as well (mostly, it was a manual tsort for each new patch, and the attempts to provide patches in the same format were doomed to failure because of this). If you have a dependency on any other qmail patches for your installation, well, then you are exponentially screwed. 8-). The problem is that as you maintain your patches, and the patch vendor maintains their patches, and DJB maintains his code, you end up with network effects. The reason I wrote the original patchkit in the first place was because we had this sort of thing going on against 386BSD 0.1, and we had to serialize application of patches from different vendors. It only worked because a human (originally, just me, later Rod Grimes, then Nate Williams then Jordan Hubbard) first picked an arbitrary order of application, and then enforced it, manually resolving the patch conflicts, thus setting the order in concrete. If Bill Jolitz had actually been an active maintainer, this would have melted down fairly quickly from the network effects. As it was, it only worked until it hit the scaling wall of the number of patches that could be serialized through a single point without real control of the source tree (Linus does this still, with real control in hand). The NetBSD breakout was an early effect based only on control; if they had funneled patches through the serial number assignment (and thus the topological sort and conflict resolution process), 386BSD + Patchkit would have survived a lot longer (IMO -- Bill Jolitz was far from publically active). In any case, all this means that I think your suggestion on how to deal with the qmail patches in the face of an intransigent active maintainer means "instant meltdown". I personally would not waste my time on it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
