[OOTB-hive] Honeycomb vision revised

Fri Jul 22 10:47:21 BST 2016

This discussion ties in with some things I've been thinking/blogging
about recently so I thought I'd add my 2p.

In my mind there are two potential audiences for Honeycomb:
1) People who want a best of/most stable version of CE and run it out of
the box in production
2) People who want a best of/most stable version of CE and run it in
production but have their own customizations as well

I fall into category 2 and although I support the idea of Honeycomb I'm
not using it at present.

To come back to Jeff's vision what would help me is as follows:

1/2) I must admit I find addons.alfresco.com somewhat overwhelming so
just have the javascript console - it seems like it would be handy to
have a way to know about and install some of the very generic, very easy
to install/use easily integrated addons

I feel like I'm always waiting for a fix for something to get a release
- even when it's a very trivial fix there can be considerable effort
involved in patching, and then updating/removing the patch when it's
changed/fixed in a stable,released version so it's something I'm
reluctant to do even though it is necessary at times (although I have
started on a tool to help with upgrading in general
https://github.com/wrighting/upgrade-assist).

I do appreciate the idea of providing patches/fixes/enhancements and
sharing community efforts in this area but how to do it without making
upgrading your own customizations (even) harder?

I need to be able to integrate my own customizations, built with the
SDK, easily.
While we'd be happy to contribute/share anything we've done
(https://github.com/cggh/cggh-alfresco-extensions/wiki) I don't think
there's anything sufficiently generic in there (certainly in it's
current form).
At least some of the potentially generic stuff is, for the foreseeable
future, too difficult to provide as an add-on although I've tried to
share the knowledge (https://github.com/wrighting/alfresco-cas)

So how to identify any conflicting patches/add-ons (similar point to
above) and update them appropriately when upgrading? e.g. we restrict
permissions on site creation and the SiteService_security definition has
changed twice recently which is tricky to spot (without my tool...)

There are different parts to this - fixes and enhancements - pretty much
as Heiko/Axel say

Fixes - just fix something that's broken (and have some degree of
confidence that nothing relies on the broken behaviour - there is after
all a reason that Alfresco go through all that testing...)

Enhancements, again can be split into two categories - the boringly
simple patches that don't warrant an addon of their own, the
long-standing, simple, TODOs that Alfresco won't get around to but
enough people want

Non-conflicting - doesn't change the OOTB behaviour without additional
steps and, can be removed and will revert to the OOTB behaviour

Conflicting - changes the OOTB behaviour by default and/or not easily
removed

The issues I see with providing enhancements are:

  * deciding what enhancements to include
  * facilitating the extra work to make it generic/non-conflicting
  * best practice/quality control
  * making the upgrade process harder

Documentation could help with facilitating the extra work - there are a
limited number of things that it would help to know how to do e.g.
providing new, per user and/or per site, options; creating new groups;
inserting new scripts into the repo ...

Some examples of things we do, or would like:
the ability to restrict site creation - we just restrict to admins which
is pretty easy but adds to the upgrade overhead - the nice way to do it
would be to create a group that has permission, which by default
contains everybody
providing scripts to provide email notifications on Site Discussions -
just done via scripts in the repository and actions - would be good to
make it possible for site admins to easily enable this and users to
disable (I know of other people who would like this but aren't confident
to configure scripts and actions)
it would be useful to have a mail action that allowed you to optionally
set headers e.g. to set auto-submitted, X-Auto-Response-Suppress headers
- this could be done by providing a new mail action, which seems
overkill, or by overriding the existing one, which feels dangerous

3) Identify what is the most stable version of Community Edition
For example it's arguable that 5.0.c was more stable than 5.0.d and at
the moment would it be better to go with Repo 5.1.g/Share 5.1.f or Repo
5.1.g/Share 5.1.g?
I know there are bug fixes I want in Share 5.1.g but it's part of an EA,
but still 5.1...
To say nothing of two GA releases with 5.1

Upgrading is a pretty big commitment
(http://tech.wrighting.org/2016/06/upgrade-time/) so probably something
I only want to do about once a year at most

On 21/07/16 18:08, Heiko Robert wrote:
> we had this kind of discussion very often and ended up in three
> independant artefacts: one bug patches module, one feature and one
> sharepoint patch module (since it is already a separate kind of thing).
>
> We also try to not patch if possible but the price is in many cases
> higher complexity, indirection and more work on updates sombody needs to
> understand. This is just my personal feeling and we would make a very
> good job if we handle bugs and missing features / extensibility in a
> better, transparent way which would be an ongoing job and should be
> accompanied by how to's, public discussions and documentation ...
>
>> One problem I see is that people that already provide this kind of added
>> value as part of their business may be reluctant to part with the
>> advantage this provides them with on the market.
> I can only speak for us: we don't sell these modules and give them for
> free but would appreciate any joined forces following required quality
> requirements to implement and maintain them. We definitly wouldn't work
> on our own patch project if there is a common one everybody can rely on.
>
> We should implement several circles of trust how changes find their way
> into the repo like handled in the linux or postgres world.
>
> And yes: I agree that this mission should be handled separately from the
> others.
>
> Am 21.07.2016 um 18:32 schrieb Axel Faust:
>> Tahir also references patches in the ADDONS topic I started today.
>> I think a lot of people agree on the "patches" part, that they should
>> not be limited to just "critical" but also the boringly simple patches
>> that fill feature holes or just implement a long-standing TODO that
>> Alfresco never got around to. Managing them in some kind of a central
>> way is also something I see as crucial, but would try to separate
>> patches from features, and use opt-in activation wherever possible.
>>
>> One problem I see is that people that already provide this kind of added
>> value as part of their business may be reluctant to part with the
>> advantage this provides them with on the market. This may seriously
>> limit our ability to compose/maintain, as this likely affects those
>> members that would be best qualified to compose / maintain this.
>> We also would need to find a way to overcome our potentially very
>> different means / approaches to how patches are done to achieve
>> something that is consistent, and easy for others to contribute to.
>>
>> And from my experience, I'd have to say that - with the right approach /
>> techniques - most files don't actually need any patching / override at
>> all to fix / change behaviour.
> _______________________________________________
> OOTB-hive mailing list
> OOTB-hive at xtreamlab.net
> http://www.xtreamlab.net/mailman/listinfo/ootb-hive

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-hive/attachments/20160722/ae236443/attachment-0001.html>