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


Reply via email to