Hi Adam,<div><br></div><div>We certainly respect your contributions and would be glad to integrate them to vtiger svn.</div><div><br></div><div>To start with, your current patch for caching user privileges file, is a good one. Its a good start in terms of eliminating the global variables and moving towards Object Oriented Concept. We certainly feel, this patch is worth it and should be part of vtiger source. But, as you know, this is going to have a high impact and the testing effort involved is slightly higher. So we need to schedule it in a right timeframe when not much changes are parallely pushed to svn. We shall definitely look for the right time slot sooner and update you.</div>
<div><br></div><div>Regarding your other patches submitted, we have been evaluating the patches submitted by different community members on trac and including them as and when possible, based on the priority, available time and the completeness of the patch.</div>
<div><br></div><div>As few of you mentioned, definitely, On Demand service has been our high priority task. But that doesn't mean we are giving up on Open Source. On Demand version and Open Source version have been maintained hand-in-hand. After every release of On Demand version, we are trying the maintain the Open Source version upto-date.</div>
<div><br></div><div>Our next planned Open source release version is 5.4.0 which is scheduled to happen sometime in April or May.</div><div><br></div><div>You can find the latest 5.4.0 svn source here:</div><div><a href="http://trac.vtiger.com/svn/vtiger/vtigercrm/branches/5.4.0/">http://trac.vtiger.com/svn/vtiger/vtigercrm/branches/5.4.0/</a>
</div><div><br></div><div>This is upto date with our last 2 On Demand releases after 5.3.0 release. The latest On Demand release changes will be integrated to 5.4.0 by Monday.</div><div><br></div><div>We apologize for are delayed responses and for any of the contributions not included to vtiger code base, unintentionally.</div>
<div><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 8:57 PM, Adam Heinz <span dir="ltr"><<a href="mailto:amh@metricwise.net">amh@metricwise.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Feb 10, 2012 at 4:08 AM, Manilal K M <<a href="mailto:libregeek@gmail.com">libregeek@gmail.com</a>> wrote:<br>
</div><div class="im">> AFAIK, vtigercrm is no longer qualified as a community project. It's<br>
> Open Source, but the developer's priority is always the On-Demand<br>
> stuff and they patch(don't expect a diff, only over-writing) the<br>
> so-called community version when they have *time*.<br>
<br>
</div>To this point, doing merges on such a large non-uniform subversion<br>
codebase is brutal. Other than the obvious monetary incentive to<br>
attempt to get people to use the On Demand version over deploying<br>
their own, I don't see any reason to develop in a hidden branch and<br>
merge back to trunk. This defeats the point of trunk and introduces<br>
unnecessary merge headaches.<br>
<br>
Anyway, since there were a couple introductions in this thread<br>
already, here's mine:<br>
<br>
I've been doing professional software development for a dozen years or<br>
so, about 50/50 desktop/web. I do sysadmin-type stuff when I need to.<br>
I've done source control administration before, so I know a bit about<br>
branch-on-policy-change and other source control design patterns, and<br>
what a PITA merging can be if it's not managed well. I do a fair bit<br>
of server deployment these days and at some point hope to open source<br>
my vtigercrm puppet module. I've been working at my current position<br>
a little over a year. Between Bryan (a co-worker who gets credit for<br>
some of the patches I upload) and I, we have about 1.5 FTE of<br>
vtigercrm development. We are producing a lot of code. This brings<br>
me to our current situation.<br>
<br>
Merging stock 5.2.1 into our 5.0.4 fork was awful. I seriously spent<br>
almost a week doing the initial merge, then several weeks after that<br>
finding and fixing broken behavior. I don't ever want to do that<br>
again. That means that my best option is to split our proprietary<br>
work into custom modules and get as many of my generally useful<br>
changes into trunk as possible. I have submitted less than ten<br>
patches out of the roughly one thousand internal Bugzilla tickets we<br>
fixed last year, but have had zero patches accepted. This is<br>
seriously throttling on my enthusiasm towards submitting additional<br>
patches.<br>
<br>
So how do we fix this situation? First off, a centralized source<br>
control model means that the onus is on vtiger to do this work<br>
gratis. They're a business, they have to keep the lights on, and if<br>
that means they prioritize their On Demand offering over the community<br>
edition, then it's unfortunate, but can we really fault them? I'm<br>
thinking out loud here, but what if they mirrored their On Demand svn<br>
repository on GitHub, then we created a community fork off of that?<br>
_______________________________________________<br>
<a href="http://www.vtiger.com/" target="_blank">http://www.vtiger.com/</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<br>Asha<br>vtiger Team<br><br><b>Connect with us on: </b><a href="http://twitter.com/#%21/vtigercrm" target="_blank">Twitter</a> <b>I</b> <a href="http://www.facebook.com/pages/vtiger/226866697333578?sk=wall" target="_blank">Facebook</a> <b>I</b> <a href="http://blog.vtiger.com/" target="_blank">Blog</a><b> I</b> <a href="http://wiki.vtiger.com/index.php/Main_Page" target="_blank">Wiki</a> <b>I </b><a href="http://forums.vtiger.com/" target="_blank">Forums </a><b>I</b> <a href="http://vtiger.com/" target="_blank">Website</a><br>
<br>
</div>