[OOTB-hive] Honeycomb vision revised

[Heiko Robert]

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.