[OOTB-hive] Call for contribution: Let's build a comprehensive module of bug patches!

Fri Aug 26 14:08:25 BST 2016

Even with "api-compatible" changes we need to be careful as they may be
"behaviour-incompatible". Yes, every bugfix is essentially a
behaviour-incompatible change, but these can and should be differentiated
between "plain stupid" / "bad coding" / "little to no consideration for
real life use-cases" errors/behaviors and specific, conceptional design
decisions or even behaviour dictated by external specifications.

I.e. one patch mentioned in IRC that Angel Borroy had done (
https://issues.alfresco.com/jira/browse/MNT-16641) is close to being
border-line. Someone at Alfresco explicitly decided how the CMIS spec about
secondary types needed to be interpreted and applied to the Alfresco CMIS
integration. Clients / integrations may rely on that specific behaviour and
explicitly check for null-values.
Fortunately, the interpretation has no strong basis in the spec and the
implementation causes real functional limitations with regards to how the
Alfresco data model works in CMIS context, so a patch for this is still
"valid" for inclusion in a patch module.

If / when we move this under an "Order of the Bee" umbrella I hope we have
by then agreed on a process of adding patches that requires some sort of
review with 1st and 2nd opinions, i.e. before a PR or branch is merged into
the main line. Basically some sort of sign-off that is common in other open
source collaborations / projects.

On 26 August 2016 at 14:52, Benjamin Kahn <xkahn at zoned.net> wrote:

> Good.
>
> (Although I don't see any movement in the ticket i linked, which is too
> bad.)
>
> There needs to be a discussion around what kinds of patches are accepted
> or desired.
>
> I think an API-incompatible change would be a problem and this patch needs
> to be applied upstream.
>
> On Fri, 2016-08-26 at 10:05 +0200, Axel Faust wrote:
>
> The import patch will not be included (see ticket updates).
>
> It is one aspect of "figuring out how the patch addon will work" to find
> ways to selectively apply patches. If you take a look at the project, you
> should see we use config flags in alfresco-global.properties to select the
> patches we have so far. This allows users to dis/enable patches even if the
> addon carries around multiple fixes. Only when patches overlap with regards
> to classes / files affected may it be difficult to differentiate.
> On 26 Aug 2016 09:56, "Andreas Steffan" <a.steffan at contentreich.de> wrote:
>
> I really appreciate a bugfix extension, but this script "import" things
> raises a few worries here.
>
> I fully agree that the "import tag" is terrible due to it's "IDE breaking
> nature". However I consider this one of the few things which really has to
> be addressed by Alfresco. I for one would never build any code relying on
> this fix applied as a "community patch".
>
> I may have missed it, but are there any policies around the bugfix effort?
>
> Will all things "carried around" be applied no matter what?
>
> I mean pretty much every extension has issues, and I expect this one to be
> no exception. If this spirals out of control, one may be better off not
> applying it at all.
>
> regards
> Andreas
>
>
> On 08/25/2016 04:55 PM, Axel Faust wrote:
>
> As the original reporter of that script import API enhancement I am glad
> this appears still relevant to people, although I don't consider this an
> actual bug to be patched. A nuisance, yes, which is why I prepared that
> contribution all these years back and which is also why I included
> AMD-style module loading in my Nashorn engine module.
>
>
> I have updated my example project https://github.com/AFaust/irc-
> alfresco-patching-samples which I had started after our discussions
> yesterday to add demonstrations / support of the following concepts:
> - support for configuring Share placeholder values via
> share-global.properties files
> - support for configuring Share Log4J logging via module-based
> log4j.properties files
> - support for configuring Share addons in a method consistent with
> Repository-tier modules (in a structure like alfresco/module/xyz/)
>
> I have also added a couple of Surf / Aikau related patches for testing
> purposes (all the above has been tested on 5.1).
> Additionally, I have included the slf4j-log4j bridge JAR in my Share
> module so I don't have to use neither the awkward Commons Logging API nor
> any other specific implementation API (I prefer the abstraction SLF4J
> provides).
>
> @Lutz: Please have a look if you consider the three "support"-concepts I
> listed as acceptable for a patch module. Opposed to what we discussed in
> IRC, I have not yet created PRs for any of this to avoid pushing things
> some people might feel do not belong in such a patch collection.
>
>
> @all: During the discussions on Wednesday we also touched on the
> possibility that such a consolidated patch addon might be put under an
> official "Order of the Bee" umbrella, i.e. the main project repository
> could be placed inside the GitHub OrderOfTheBee organisation. At least I
> consider all the current activities a part of "figuring out how such a
> consolidated patch module should work / be maintained".
>
>
> 2016-08-25 15:52 GMT+02:00 Lutz Horn <lutz.horn at ecm4u.de>:
>
> Hi Benjamin,
>
> I've added a GitHub issue for your proposal:
>
> https://github.com/ecm4u/ecm4u-alfresco-bugpatches/issues/3
>
> Lutz
>
> --
> Lutz Horn
> ecm4u GmbH
> Hölderlinplatz 2b
> 70193 Stuttgart
> http://www.ecm4u.de/
>
> t: +49 (711) 912 775-73 <%2B49%20%28711%29%20912%20775-73>
> f: +49 (711) 912 775-80 <%2B49%20%28711%29%20912%20775-80>
>
> ecm4u GmbH - die IT in Prozessen einfach sinnvoll nutzen
>
> Handelsregister: Amtsgericht Stuttgart HRB 734004, Geschäftsführung: Heiko
> Robert
> _______________________________________________
> OOTB-hive mailing list
> OOTB-hive at xtreamlab.net
> http://www.xtreamlab.net/mailman/listinfo/ootb-hive
>
>
>
>
> _______________________________________________
> OOTB-hive mailing listOOTB-hive at xtreamlab.nethttp://www.xtreamlab.net/mailman/listinfo/ootb-hive
>
>
>
> --
> Andreas Steffan
>
> Achter Billing 14
> 22399 Hamburg
> Germany
>
> skype: deas0815
> M: +49 160 4694826
> T: +49 40 23943542
> F: +49 40 23943542
> http://www.contentreich.de
>
> Contentreich : Alfresco ECM, Clojure, Groovy und WordPress - aus Spaß und für Geld
>
>
> _______________________________________________
> OOTB-hive mailing list
> OOTB-hive at xtreamlab.net
> http://www.xtreamlab.net/mailman/listinfo/ootb-hive
>
> _______________________________________________
> OOTB-hive mailing listOOTB-hive at xtreamlab.nethttp://www.xtreamlab.net/mailman/listinfo/ootb-hive
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-hive/attachments/20160826/6779aa38/attachment-0001.html>