On Monday 16 September 2002 06:38, Erich Titl wrote: > can't quite follow you there as I don't know the merits of Qmail > which have been heavily discussed in the Sendmail news group. > Sendmail itself has quite a closed development model and if I > understand the DJB license correctly there is not much open about > that source.
Well, IMHO, Qmail is written by Dan Bersteing (a former Sendmail developer) who was frustrated with what he considered "bad code" within the Sendmail SRC. Dan wrote Qmail as a proof of concept towards what he felt Sendmail "could" be. It's a great MTA, however the source is not released because Dan feels that others would modify it in ways he felt would not be acceptable. Qmail is terribly documented IMHO, however I feel it is the best Linux MTA available and have never had a problem running with it properly configured. You are exactly right in that Qmail is not OSS, as remains true with about every DJB utility. > >I can't really blame him. Putting the source in CVS should be a > >requirement, however only the lead developer should allow write > > access to that CVS branch. > > I believe the Linux kernel group must have this kind of a model. It > could very well be applied to LEAF but it would require a decisive > position (probably the lead developer) which decides if something is > entered into the source tree. This of course would require that the > lead developers agree to such a task which is time consuming. Else > someone else would be required, someone who is trusted by the lead > developer. Absolutely, I didn't necessarily interpret your desires to accept this type of access. > Absolutely, but have a look at some low level commercial products > like the Zyxel routers. They are far from being perfect but a trained > monkey could do a primitive set up. Is there a high demand for this? It would be rather easy to do, but I wouldn't necessarily want "LEAF" stamped on it in regards to the existing LEAF variants. I feel the finished "web-config" product can and will meet this criteria and other requests that would be forthcoming if such a product was available. > >How exactly would you bring this about? Every LEAF variant has a > >considerably different kernel config and init/configuration > > system..... 2.2.x and 2.4.x systems require completely different > > init systems and are NOT compatible; this doesn't even consider > > glibc differences between several branches. I would find a common > > CVS branch > >between existing LEAF releases impossible to create NOW, and > >likely impossible at any time in the near future. > > This IMHO is one of the weaknesses LEAF has. I believe we could live > with a single 2.2 kernel, hopefully we could find a tree for a single > 2.4 kernel. The same can be true for the init systems. And I agree > with one post lately on this list that we should be able (not forced) > to get rid of glibc dependencies. This would be possible to do, "IF" the user gets all the dependancies correct. Personally, I feel the required dependancies of such a system (right now) would overcome any benefits. This would be MUCH easier if each LEAF variant had its own SRC CVS tree or ports system and be much easier to maintain. > >All developers already have "private" cvs branches via the /devel > >branch.... I am likely to be missing your intentions, could you > > explain a little more fully??? > > Of course they do and they always will, but having a common place > where one can check out the source for a LEAF product would be nice. /cvs/src/"variant" would likely be the clearest, anything not incorporated within the "official" variant would be left to the individual developer/maintainer. One such example would be my "udhcp" package... I don't expect anyone else to supply it or the source and I have linked the souce at the same place as the binary. This package is not "stock" in any LEAF variant, and not maintained by any variant lead-developer, so they should not NEED to maintain this package (or it's source). Could there be a better place for the binary or it's source? I don't feel so, and it presently depends on glibc and incompatible with some LEAF systems in the present form. I'm just fishing for a suggested "better method", rather than intending to be negative.... if there is a "better method" available, I am sure all of us would be glad to incorporate it. > We cannot expect anyone of the developers to come forward with > anything else they are used to. After all they defined their > preferred environment. My unwillingness to have UML stems from > missing experience and the limitation of a running server system and > that is definitely my own problem. Still it would be nice to have a > standardised chrooted environment where I can do development, and it > would be nice if it is maintained in a state where I can trust > anything developed with it will work on a defined branch. If we could > distill such an environment from what is used by the various branches > maybe the developer base would find it interesting to use it. My > experience is that standards are good, evolving standards are even > better. Standardization seems like a "uncomforting word" to many developers. At what baseline are you considering "standard". I'm sure you realize that 2.2 and 2.4 kernels demand different patches and init process. To further the standardization, Oxygen, Wist-dist, and Packetfilter have a different boot process altegether. I would highly suggest going over Serge's changelog with PacketFilter to get an idea of what I mean. My last consideration would be if Charles or someone does actually write a bootloader in Forth......where would the baseline be then when Syslinux is replaced??? I think I'm following your idea, but I don't think a central LEAF repository could be clear and easy to follow UNLESS things were seperated by variant. Or am I wrong??? -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ------------------------------------------------------- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
