On Sun, May 13, 2012 at 2:12 PM, Gert Doering <g...@greenie.muc.de> wrote: > 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).
First, I was gentoo developer for some time, and maintained, among other, openvpn packages. The case of xorg is not similar, you keep using this example while in the openvpn case we have a core and a set of optional plugins, that's all. So please give appropriate example. One example of your approach is the bluez project, which insist of using in-tree plugins not because it is the simpler approach, but this way it can enforce GPL license on all plugins and make sure they are stay opened. > 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*. I think I already stated some advantages, you can ether accept or reject but at least they are focus on the subject at hand: 1. we remove dependencies from the core openvpn package. 2. we can release a fix in plugin without releasing the complete openvpn. 3. plugins are optional, user may install the plugin as separate pacakge if needed. 4. we can delegate maintenance of plugin. 5. we can attract more people to the community. 6. simpler to track the history of atomic components in the mean of source control. > > 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". Hmmmm... I think that you are at the xorg example again... > 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. OK... now you are talking... so you say that like apache we need to integrate the plugins to main build system, this was the other alternative. > > 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
