<div dir="ltr"><div style>TLDR: rant</div><div style><br></div><div style>On Wed, Apr 10, 2013 at 1:33 AM, Sreenivas Kanumuru <span dir="ltr"><<a href="mailto:svk@vtiger.com" target="_blank">svk@vtiger.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>One of the key objectives of Vtiger 6 is to<a href="https://wiki.vtiger.com/index.php/Vtiger_6_Developer_Guide" target="_blank"> improve developer experience</a><span></span><span></span><a></a>.</div>



</div></blockquote><div><br></div><div>This statement doesn't make any sense.  Your development process is opaque and exclusionary -- for all of your projects.  I don't see how a MVC refactoring in a single project has anything to do with improving developer experience.  Quick tip -- ripping and replacing your view layer forces me to rewrite a dozen custom modules -- with time I don't have.  Does that sound like an improvement in my "developer experience"?  As things stand, there is a non-zero chance that we will not move to vt6 at all.</div>

<div><br></div><div>Real projects that improve developer experience are not poorly tested massive global rewrites.  They are unsexy refactoring tasks.  Here's a short list:</div><div>- Rip out prototype and use jQuery exclusively</div>

<div>- Rewrite core entity modules to use vtlib</div><div>- Finish vtlib; there are gaps in the implementation [1] <i>et al</i></div><div>- Replace PearDatabase class with direct ADOdb access</div><div>
- Move HTML generation out of internal functions into Smarty templates</div><div><br></div><div>Real processes that improve developer experience are not lip service on developer mailing lists.  They are visibility and automation.  Here's a short list:</div>
<div style>- Actually work out of Trac.  When you apply a patch, Trac should be updated immediately.  When you decide to work on a new feature, Trac should be updated immediately.  On more than one occasion, I have found myself implementing a feature against 5.0.4 that later appeared in 5.3.0 or 5.4.0, so I get to throw that work out in an attempt to keep our fork closer to trunk.  Frustrating!  It's even worse that your release schedules are so long.  What web company releases on a one year cycle?  Check out how Joomla does releases -- they do five point releases, then x.5 becomes a security maintenance branch and they go on to the next major.  They are working hard at a clean separation of cms and platform (which compares to crm and vtlib).</div>
<div style>- Automated testing!  I have my own experience with TDD and recognize how difficult getting proper browser boxes set up can be, but start with vtlib!  It's nicely broken up into testable classes.  I think I've even submitted a couple PHPUnit tests along with patches to vtlib.</div>
<div style>- Ask for help, discuss upcoming work, etcetera.  As things stand, this mailing list should be renamed not-vtigercrm-developers@.  Check out any other developer mailing list and you will see orders of magnitude more internal developers.</div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div>Vtiger 6 will come with built in Upgrade tool to ensure smooth migration for Vtiger 5 users.  As Prasad noted, we are promptly responding to issues reported on <a href="http://trac.vtiger.com/cgi-bin/trac.cgi/report/37" target="_blank">Vtiger 6 code base</a>.<br>



</div></div></blockquote><div><br></div><div>You need to promptly respond to all issues, even if they are in legacy releases.  You need to go back through your bug backlog and assess each bug, either fixing it on the 5.x line, closing the bug as WONTFIX, or moving the bug forward to a 6.x or future release -- even a "big pile of unscheduled features".  I would be more than happy to see changes on my bugs like, "This patch doesn't apply against the 6.x line, could you please rewrite it?"  Instead I get crickets and dust.  Are you familiar with feedback loops?  If you want to modify a behavior, you respond quickly and appropriately.  What behavior would you like to see from the developer community?  If it is submitting bugs and patches, then  reinforce those behaviors with positive stimulus.  If it is bitching and moaning on the developer lists, then just keep doing what you're doing.</div>

<div><br></div><div>[1] <a href="http://trac.vtiger.com/cgi-bin/trac.cgi/browser/vtigercrm/branches/6.0.0/vtlib/Vtiger/Block.php#L103" target="_blank">http://trac.vtiger.com/cgi-bin/trac.cgi/browser/vtigercrm/branches/6.0.0/vtlib/Vtiger/Block.php#L103</a></div>


</div></div></div>