[OOTB-addons] [OOTB-hive] Inclusion Criteria overview remarks

Thu Feb 5 13:37:30 GMT 2015

Ok, let’s see if I can address this quickly (still at work)

These are not necessarily contradictions, but in the brevity I was aiming for it may not be immediately clear. That is why there are also some more detailed explanations linked for individual “Category” values.

Technical #11 states that any build tooling procedures must produce an identical result. But a project may not provide build tooling with the source at all, since #10 is a SHOULD, not a MUST
You can most definitely deliver an ADDON as just an AMP / JAR and source without build tooling. Note that license #1 and #3 state that there should at least be access to source for evaluation purposes.

About technical #22: Some people use “nodeService” instead of “NodeService” beans for access “in the name of a user” (different to the currently logged in one) and thus circumvent security. runAs() should be used in combination with the proper services (always “NodeService” public bean).

We can definitely argue for SHOULD / SHOULD NOT for #22 and #23. From my perspective it is more towards MUST / MUST NOT as any conscious circumvention of security is unacceptable. I also had issues with addons that refused to work when “admin” was deleted or that did not work for a user other than “admin” (a tool supposedly aimed at administrators – note the plural)

What is vague about technical #30? Should we explain what “bytecode instrumentation” is?

“I find that the Technical specs go too much in detail. This means we need to have the source code in all cases and need to check it thoroughly. I wasn't aware that this was our goal.“

That is exactly why I wrote the draft. The previous discussions about “goal” and extend of criteria were non-conclusive (a lot of “in my opinion” but no consolidated result) and it may have been difficult for one side or the other to understand what the other would like to have. We can find the right balance by taking this as a starting point and discussing about what to add / remove or reduce in severity.

About the level of detail: This is only scratching the surface – I deliberately left out about 70% of items I would like to check if I could have my way.
For comparison: Reviewing the JavaScript Console addon based on this catalog took me about 2 hours if I don’t count the time I was fretting about the layout of the report.

”We are not the people who will voluntarily give a detailed development/test report for people who develop Addons.”

Why not? What is our (added) value to the community if we just do some end-user tests and addons are allowed to have serious side effects if combined with one another or used without being aware of them? Our report (see https://github.com/OrderOfTheBee/addons/blob/master/addon-reviews/JavaScript%20Console.md for an example) definitely does not have to be so detailed that we do the work of the developer, but should give valueable and substantiated pointers.

I would be open to doing a “pair review” of another addon with another member of this committee. Before we end up dismissing the current draft based on the current length/extent, it should at least have been tried in practice by another person.

Regards
Axel

Von: OOTB-addons [mailto:ootb-addons-bounces at xtreamlab.net] Im Auftrag von Axel Faust
Gesendet: Donnerstag, 5. Februar 2015 14:01
An: ootb-addons at xtreamlab.net
Cc: ootb-hive at xtreamlab.net
Betreff: Re: [OOTB-addons] [OOTB-hive] Inclusion Criteria overview remarks

I’ll just move this to the ADDONS mailing list for which it was intended (based on the Google+ hangout where we discussed the mailing list issue)

Von: Tahir Malik [mailto:tahir.malik at contezza.nl]
Gesendet: Donnerstag, 5. Februar 2015 12:48
An: ootb-hive at xtreamlab.net<mailto:ootb-hive at xtreamlab.net>
Betreff: [OOTB-hive] Inclusion Criteria overview remarks

I got the mailing working, didn't know what happend but didn't receive any ootb-hive mails since a couple of months.

So getting back to  this list: https://github.com/OrderOfTheBee/addons/wiki/Inclusion-criteria-overview

I guess there are contradictions stated.......

Like Technical 1 is must "available in package form that either supports installing from command line, via build tools or as drop-in, or uploading into Alfresco data dictionary at runtime"
Technical 10 is should "source provided with build tooling"
Technical 11 is must "build tooling produces result identical to pre-built artifacts for unchanged source"

So in this case if just have an amp file or jar file according to 11 it must be build-able by a tool and can't be delivered by as just an amp/jar.

Technical 22 is vage "use runAs() instead of unsecured private service beans to execute code with elevated privileges or as substitute for other users"
Technical 23 should be a should not instead of must not "require existence of super user called "admin" (e.g. runAs(work, "admin"))"
If this is so, then this means you can only do work as yourself instead of someone else. Sure this 'might' be a security issue but stating it must not is a bit too much.
I use repository webscript as runas System or admin and do stuff a normal user can't. Thats inevitable sometimes, like you want to move/change something in RM which only admin can do but you as a user want for example a report.

Technical 30 is vage muust not "require bytecode instrumentation except for experimental features"

I find that the Technical specs go too much in detail. This means we need to have the source code in all cases and need to check it thoroughly. I wasn't aware that this was our goal.
I guess we should simplify the criteria so we can do a faster check on Addons and aren't too strict about stuff.
We are not the people who will voluntarily give a detailed development/test report for people who develop Addons. I wish I had a group like that who voluntarily checked all my code and give me a report :P.

It's good to have these criteria prior to inclusion, like send/notice these criteria to the Addon developers that this is the best practice to have you Addon developed.

Best regards,

[Contezza]

Tahir Shazad Malik

email

tahir.malik at contezza.nl<mailto:tahir.malik at contezza.nl>

mobile

+31 (0)6 14 77 50 82

office

+31 (0)848 68 89 02

website

www.contezza.nl<http://www.contezza.nl>

[linkedIn]<http://nl.linkedin.com/in/tsmalik/>

[Twitter]<http://twitter.com/tahirshazad/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-addons/attachments/20150205/f6d5e320/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 4470 bytes
Desc: image001.gif
URL: <http://www.xtreamlab.net/pipermail/ootb-addons/attachments/20150205/f6d5e320/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 523 bytes
Desc: image002.gif
URL: <http://www.xtreamlab.net/pipermail/ootb-addons/attachments/20150205/f6d5e320/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 493 bytes
Desc: image003.gif
URL: <http://www.xtreamlab.net/pipermail/ootb-addons/attachments/20150205/f6d5e320/attachment-0005.gif>