All non trivial software has bugs – that’s just the ways it is. Alfresco is no exception – neither Enterprise nor Community edition. The major difference between these two versions is that you pay a subscription which provides support in case you run into “some kind of trouble” with the Enterprise product – bugs being a special case. We once bumped into a CMIS-QL problem with the Enterprise edition and Alfresco support provided us with a patch quite quickly. I have not checked whether this fix has has found its way into the Community edition.
Enterprise edition and the new Alfresco Team product may not be “the right” choice either for cost or other reasons. I fully understand that providing product support boils down to cost and hence, restricting flexibility of a product (Alfresco Team) is one approach to cut effort.
Anyways, I am sure there is still a significant amount of “brave” people (like us ;) running Alfresco Community in production.
What do we do, when we get affected by a production critical bug (happened to us more than once) ?
Alfresco and certified partners don’t help, now what ?
When I found ourselves in this situation, I usually googled and worked my way through the forums and JIRA picking up hints on the way. I cannot remember a single case where we have found a patch “ready to apply” against an official release, so usually, we had to fix the release code revision (as in svn) ourselves (the hints picked up during investigation more or less helpful). A few weeks ago it was ALF-2880 (patch against 3.4c below) and ALF-6182.
I wish we (as the community) had something – a system and/or process to support our bugfixing needs. A place to exchange community release (bugfix) patches. Google Code, github, sourceforge all work fine for extensions, but they don’t work well for “core changes”. Of course we could (technically) just attach patches to the JIRA issues, but I’m not sure whether that is fine with Alfresco people.
Anyone else feeling the need for better bugfix support in Alfresco Community ?
PS: We have been asked quite a few times what exactly is covered by Enterprise support subscription and how to handle the support situation when Community edition is used.
Update 04.08.2011
Alfresco JIRA ALF project description states:
Global project for Alfresco development – for Community issues,
Maybe I get something wrong, but I don’t quite understand why ALF-2880 (as an example) gets updated to
Resolution: Fixed
Fix Version/s: 3.3.5, 3.4.0 Enterprise
I agree with you. I have been adding my “bugfixes” in my blog but is not the best way to share them.
Alfresco JIRA has both a CE and EE bug list but usually the fixes are proposed in terms of EE version, so it should be necessary to check periodically the svn to see if the bug reported has been solved and uploaded to SVN because the merge points are not public
Seems, we are not alone.
Isolating and/or backporting a fix can get quite a bit of effort, and even frustrating when you get the feeling other people have been there before or will get there sooner or later.
A few weeks ago, I was wondering whether it would make sense to switch from svn to git(hub) for CE source code control. I guess it would serve certain needs better than the svn based solution we have today and it would even extend the scope from “bugfixes” to “core system changes”. I have no clue whether that is feasible at all, but it should be allowed to express a wish. :)
Definitely, you should be submitting patches through Jira. But of course the problem is that those patches will never result in an Alfresco-supported maintenance release or hotfix for Community, at least using the processes we currently have in place.
They will get taken up into Enterprise, but that doesn’t address your problem.
What are some options for addressing this, in your opinion?
Jeff
Hallo Jeff,
I don’t have a definite answer to your question, as I cannot really judge the whole situation (legally, politically and technically).
As a community contributor, I personally would appreciate my own forked alfresco “core code” git repository where I can do whatever I want and offer pull requests to a central manged “hotfixed community” branch.
In this approach, one would somehow have to make sure upstream changes from Alfresco get into this hotfixed branch as well. I may be possible to leverage git-svn syncing with another (upstream) branch here.
Community contributor changes and alfresco upstream patches (technically) could get merged into the “hotfixed community” branch.
Of course, you’d need maintainers merging changes into “hotfixed community”.
I cannot tell whether this would makes sense at all in practice. I don’t know whether there are enough community contributors or volunteer maintainers.
I guess the root causes of our “problem” are two flavors of core alfresco code and the fact that community contributors have no easy way to “commit and share”.
Maybe Alfresco can check whether it makes sense to adapt ideas SpringSource open source in general and on github (https://github.com/SpringSource).
regards
Andreas
Definitely, I agree that the “two flavors” with no easy way to “commit and share” is the root of the problem.
Based on the recent community survey, I think there are actually a smaller number of people looking to commit to core than I would have suspected. Of course, that could be because of this problem–we don’t make it easy to be a core contributor so there aren’t many that are interesting in being one.
I don’t have an easy answer at the moment. But it is something I think about a lot and I am interested in exploring paths to improvement.
Jeff
Thanks for commenting, Jeff.
The approach to choose surely depends on the scale of the problem (amount of community contributors interested in core code change management). SpringSource projects surely differ from Alfrescos in this regard.
I think I’ll go and give git-svn a try. Looks as it can improve my situation and provide a system to manage “my” core system changes.