[Vtigercrm-developers] Bugs etc - Was password vs accessKey

[Adam Heinz]

TLDR: rant

On Wed, Apr 10, 2013 at 1:33 AM, Sreenivas Kanumuru <svk at vtiger.com> wrote:

> One of the key objectives of Vtiger 6 is to improve developer experience<https://wiki.vtiger.com/index.php/Vtiger_6_Developer_Guide>
> .
>

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.

Real projects that improve developer experience are not poorly tested
massive global rewrites.  They are unsexy refactoring tasks.  Here's a
short list:
- Rip out prototype and use jQuery exclusively
- Rewrite core entity modules to use vtlib
- Finish vtlib; there are gaps in the implementation [1] *et al*
- Replace PearDatabase class with direct ADOdb access
- Move HTML generation out of internal functions into Smarty templates

Real processes that improve developer experience are not lip service on
developer mailing lists.  They are visibility and automation.  Here's a
short list:
- 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).
- 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.
- Ask for help, discuss upcoming work, etcetera.  As things stand, this
mailing list should be renamed not-vtigercrm-developers at .  Check out any
other developer mailing list and you will see orders of magnitude more
internal developers.

 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 Vtiger 6 code base<http://trac.vtiger.com/cgi-bin/trac.cgi/report/37>
> .
>

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.

[1]
http://trac.vtiger.com/cgi-bin/trac.cgi/browser/vtigercrm/branches/6.0.0/vtlib/Vtiger/Block.php#L103
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20130410/8cfb86b7/attachment.html>