Regarding Apiary -- I am too not sure it should be a MUST. In many cases we would want to adopt the tools used in one of related open source communities that we build on (e.g., OpenStack, Docker, etc), and there doesn't seem to be a wide consensus on any particular tool (to the best of my knowledge -- I am certainly not an expert in documentation tools). In general, I would suggest making the 'Summary of MUST guidelines' section more complete -- in particular, Apiary is not mentinoed there (maybe that was the reason I missed it when I reviewed the document). Few other comments regarding MUST guidelines: - the necessity to provide 'workarounds' is somewhat vague.. what do we mean by "something not available"? Can we calrify that this does not apply to requests for new features? - regarding PRs with documentation impact -- I wouldn't make it a MUST to include them in the same PR (which seems to be implied now) Moreover, regarding CI.. is FIWARE going to provide a centralized CI facility? It seems unlikely that each GE owner will be able to set up their own CI.. Regarding the 'Configuration' section -- in fact, I think the ideal practice would be to use some sort of standardized programmable configuration facility that all GEs will be able to use. Maybe something to consider, anyway. Thanks, Alex From: DANGERVILLE Cyril <cyril.dangerville at thalesgroup.com> To: JOSE MANUEL CANTERA FONSECA <josemanuel.canterafonseca at telefonica.com>, "fiware-chapter-architects at lists.fi-ware.org" <fiware-chapter-architects at lists.fi-ware.org>, "fiware-chapter-leaders at lists.fi-ware.org" <fiware-chapter-leaders at lists.fi-ware.org> Date: 01/07/2015 12:06 PM Subject: Re: [Fiware-chapter-architects] GEi Developer Guidelines : v1 candidate Sent by: fiware-chapter-architects-bounces at lists.fi-ware.org Dear Jose and all, After internal discussion with the GE owners in my chapter (Security), I would like to express major concerns about the github.com and Apiary MUST guidelines. Last week, I asked Juanjo for a slot to discuss the guidelines again on last Monday?s Architects? meeting but I received notification that it was canceled. Reason unknown to me. So I?ll try to express our concerns here then: 1. The guideline saying ?the SCM *MUST* be github.com? is hardly acceptable for us. What if developers refuse to create an account on Github.com (or other service provider out of the control of FIWARE consortium or EU regulations altogether) because they distrust their security or business model? More importantly because they don?t want to be forced by FIWARE management to give up their privacy that way? This is the case for us. It also gives us a strong feeling that it is now the policy of the EC to allow subsidizing US companies that are not bound by (e.g.) EU privacy regulations, isn?t it? So is there a reason why FIWARE cannot provide its own github instance (with Gitlab software) like we have our own instance for other tools like Jira, Gforge and so forth? OR, if not possible, at least leave the choice to partners/developers to use their own? For instance, our partner ZHAW is already running their own public github instance (https://github.engineering.zhaw.ch) that offers the same features that you get for free at Github.com. So my suggestion: either change *MUST* to *SHOULD*, OR change Github.com to ?any public Git or SVN repository that complies with requirements X, Y, Z??. 2. Same issue for ?Apiary MUST be used?. Some of us have spent considerable time developing their own documentation tools and have documented all their APIs with it. We hardly see a reason to change this. I suspect this to be the same for many other partners. (If we had known from day 1 that "Apiary MUST be used", the situation would have been different, but 10 months into the project this presents us with considerable difficulties, not least of them being the time we would have to invest to move everything over to the demanded toolset, and which we would like to spend more on making better software.) My suggestion: change *MUST* to *SHOULD*. 3. The last issue concerns the Apiary MUST guideline as well. So far we have provided the User and Programmer?s guide and API specification on the wiki. If we switch to Apiary, are we done with the wiki pages? Or will we have to provide both, in which case the FIWARE Tools team would provide some tool to generate these deliverables from Apiary automatically to avoid duplicating the work and wasting time synchronizing the two? Thank you for your understanding. We are open to discussion. Kind regards, Cyril -- Cyril DANGERVILLE, Thales Services FIWARE Security Chapter Architect Authorization PDP (ex-Access Control) GE Owner De : fiware-bounces at lists.fi-ware.org [ mailto:fiware-bounces at lists.fi-ware.org] De la part de JOSE MANUEL CANTERA FONSECA Envoyé : mardi 30 juin 2015 11:32 À : fiware at lists.fiware.org Cc : MIGUEL CARRILLO PACHECO; JUAN JOSE HIERRO SUREDA Objet : [Fiware] GEi Developer Guidelines : v1 candidate Importance : Haute Dear Partners, Here is the latest version of the GEi Developer Guidelines. https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Developer_Guidelines As you know the GEi Developer Guidelines summarize what we believe are the best practices in developing your GEi. Some of these Guidelines are a must, so this may have an impact on your work. Those Guidelines were already circulated and have already been presented at the FIWARE WG and Architects Leads conference call. We would like you to have a final look at them. Please send your final comments before Friday 3rd July. On Friday, if there are no substantial objections we will make them official as v1 of such guidelines. The only substantive change made with respect to the version presented at Architects Conf. Call has been the introduction of a (SHOULD) requirement about Docker (under binary releases section). This has been explicitly requested by our project coordinator, Juanjo Hierro. Many thanks for your help and support All the best Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição _______________________________________________ Fiware-chapter-architects mailing list Fiware-chapter-architects at lists.fi-ware.org https://lists.fi-ware.org/listinfo/fiware-chapter-architects -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-chapter-architects/attachments/20150701/d19cbddc/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy