[Vtigercrm-developers] caching user privileges

Adam Heinz amh at metricwise.net
Mon Feb 13 07:33:03 PST 2012


On Sun, Feb 12, 2012 at 5:17 AM, Alan Lord (News) <alanslists at gmail.com> wrote:
> I think the recent reply from Asha shows that they are "listening" and,
> provided the submissions are good enough/useful enough, they will get
> incorporated into trunk in a timely manner.

http://trac.vtiger.com/cgi-bin/trac.cgi/ticket/4128

I submitted my first patch to vtiger over a year ago and have not seen
a response to it.  I would be happy to see something like, "We can't
accept 5.0.4 patches, could you please forward migrate this to trunk."
 Whether or not vtiger is willing to listen, I'm not convinced that
vtiger is able to listen.  Trac affords no mechanism for watching or
voting on tickets, so there is no way to gauge how important a
particular fix is for the community.  Check out this canned "Active
tickets, mine first" search:

http://trac.vtiger.com/cgi-bin/trac.cgi/report/8

Look how many open bugs there are for shipped releases.  The bare
minimum would be to sweep all these bugs forward into the Unassigned
milestone.  Better still would be to expend the effort to determine
which of these bugs are WONTFIX or INVALID and mark them against the
current release, then prioritize and schedule the rest, especially the
bugs with patches.  This bug tracking system is showing signs of
neglect.

> Forking is only a good idea as a last resort IMHO and there needs to be
> a *big* community movement behind it. Here I do not see that at all. It
> would bring no or little benefit and just fragment the community.
>
> It is much better to discuss our issues in a grown-up manner and resolve
> them within the existing ecosystem.
>
> I also think that there is nowhere near enough
> groundswell/contributors/advocates to support, maintain and grow a
> community fork of vtiger.

With distributed source control systems (such as git), fork is not the
dirty word it used to legitimately be.  The standard way to work on
github is to fork the open source project, make the fix in your own
fork, then submit a pull request for the maintainers to pull your fix
back into the project.  So I really should have said community forks,
plural?  I am proposing picking up the ecosystem and moving it two
steps to the left, however! ;)



More information about the vtigercrm-developers mailing list