On Sun, May 13, 2012 at 12:35 PM, Gert Doering <g...@greenie.muc.de> wrote: > Hi, > > On Sun, May 13, 2012 at 12:30:37PM +0300, Alon Bar-Lev wrote: >> An healthy community dealing with openvpn need to gather all resources >> that are acting at that niche. >> There is no reason why we should not invite these maintainer to be >> part of the openvpn project, on the contrary, we gain more resources, >> more professionals. > > And how exactly will "fragment the openvpn source tree into many small > packages" invite more contribution? > > I, for one, will think twice about contributing to a project where I have > to figure out which of the 470 packages I need to download before I can > even *start* looking at things. > >> Why should we define the scope of the openvpn project based on the >> legacy james svn tree? > > Why not? > >> 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... I try to summarize people view and get: 1. it is hard to push changes to specific git repository... it is not actually hard though. 2. it is hard to maintain several packages at distro level, well, as shown in the other examples and plugins it is not the case. 3. it will grow to 500 packages like xorg, while it is not the case even in nightmares... and we are talking about pure optional components. > >> I would like to see this community growing... all UI/management/plugin >> developers working under the same roof. >> >> It is healthy to the project = more resources. >> It is healthy to the users = one stop shop, better integration. > > *one stop*. Thanks for saying that. This is a strong argument against > fragmenting our source tree. > > (I see you coming up with "why not have the different platform backends > in their own repositories each, because a FreeBSD developer would not > need the source files for Linux" next - and there is madness, not sanity) Well, not for now.... :) Although the thought came to mind when evaluating the polarssl implementation... Alon.
