David, You misrepresent my opinion. I do NOT want a split, but will deal with one (as a packager) if it becomes necessary. I would much prefer there to never be a split, and for everything to be handled with configure args or ifdefs in the make file.
----- Eric F Crist On May 13, 2012, at 15:42:10, Eric Crist wrote: > What I had mentioned might be a good alternative in IRC was to have an > openvpn package, and an openvpn-contrib. Two isn't hard, 17 or 500 is. > This, still, didn't seem to be liked by Alon (not calling you out, per se, > but stating fact). > > Not sure where we should go from here other than to stay where we are. No > point in moving until we're all ready to move in the same direction. If need > be, we can enforce a dev-team sack race when we next get together. ;) > > ----- > Eric F Crist > > > > On May 13, 2012, at 07:40:07, Seth Mos wrote: > >> Chiming in here, >> >> Although pfSense is basically a giant tarbal, it has the benefit of being >> sure that all parts of it fit together. We also have installable packages >> and we frequently see issues with that. We are trying to solve some of them >> using PBI packages just so that each "package" always has it's dependencies >> in check. >> >> Although we are just a "consumer", we'd rather have a single FreeBSD port >> that we build then 5 ports we need to update, with all the required >> dependencies. >> >> Our github repo is split into one for packages, tools and pfSense. But each >> is really a standalone thing, because there is no overlap. Which probably my >> point, the plugin is useless without the main. >> >> The one git repo for pfSense is pretty manageable, even more so through git >> with Pull requests. The single biggest jump in commits and patches from the >> community is moving to GitHub. It makes contributions so much easier. That >> said, even for us the amount of simultaneous active coders is about 5, >> although we do see small patches and pull requests from about 30 or so >> people a year. >> >> I see nagios using nagios-plugins, that has seperate releases from the main >> nagios. So there's that too. >> >> Just a few thoughts from the other end. >> >> Really, really, _really_ looking forward to Viscosity and Tunnelblick >> shipping Ipv6 enabled clients. Pretty please. >> >> Cheers, >> >> Seth >> pfSense developer >> >> Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven: >> >>> Hi, >>> >>> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote: >>>>>> Can't we progress? >>>>> >>>>> Why is that progress? >>>>> >>>>> Change always has drawbacks. If the plus sides outweighs the drawbacks, >>>>> change is good. Change for change's sake, "just because you can change >>>>> it", is not. >>>> >>>> Yes, but still from your responses I don't see any drawback... maybe I >>>> am slow learner... >>> >>> Drawback to maintainers and sysadmins has already been mentioned by >>> ecrist and me. Try being a sysadmin for a few weeks and figure out >>> which bits of xorg you need to download to install xinit, assuming >>> you have a system without any X libraries and headers yet (in the xorg >>> example: splitting off "xinit" might actually make sense, but splitting >>> the basic infrastructure to build anything into about 50 different >>> "xyz-library" and "xyz-headers" packages is crazyness). >>> >>> But the onus is not particularily on me: you have not put forward >>> convincing arguments why splitting off a very small number of files >>> that only make use in the context of OpenVPN into their own repository >>> has any *advantage*. >>> >>> The handwavy argument "it will attract more users!" can be countered by >>> similarily handwaving "I, as a user, hate to download multiple packages >>> to figure out how to start contributing, and so it will scare *away* >>> users". >>> >>> >>> As a counterexample, look at Apache. They have heaps of modules in >>> the main tarball, and have no issues with frequent release and with >>> attracting developers. And still, modules maintained by non-apache >>> developers can be developed externally, without having to splitt off >>> all existing modules beforehand. >>> >>> gert >>> -- >>> USENET is *not* the non-clickable part of WWW! >>> //www.muc.de/~gert/ >>> Gert Doering - Munich, Germany >>> g...@greenie.muc.de >>> fax: +49-89-35655025 >>> g...@net.informatik.tu-muenchen.de >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ >>> Openvpn-devel mailing list >>> Openvpn-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Openvpn-devel mailing list >> Openvpn-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
signature.asc
Description: Message signed with OpenPGP using GPGMail