Here’s your digest for today! 
#ariatosca
undefined: Indeed no git discussion was made, since it was fairly small PR. 
However, i agree we should write an approving message on the PR...
 Just saw your module, i think it could be a good idea to utilize it, but I 
think we do need to discuss the exceptions catching aspect of the DaemonThread 
(which i think is what you meant :wink:)
undefined: lots of topics to cover :slightly_smiling_face:
 1) Gitbox --> It might just be my unfamiliarity with it, but I'm just not 
really sure I understand the benefits it has to offer us? What's wrong with the 
current model? What difficulties does the Github mirror present?
undefined: 2) re `ARIA-300` and adding license headers on yaml files - This was 
actually shortly discussed on either slack or the mailing list way, way back, 
and it was my understanding that non-code files (such as these yaml files) do 
not necessarily require a license header.
This is why I added  a `.*.yaml` rule to `.rat-excludes`.
Note that if yaml files do require a header, then there are other types of yaml 
files missing it:
a) ARIA CLI configuration file - 
<https://github.com/apache/incubator-ariatosca/blob/master/aria/cli/config/config_template.yaml>
b) tests yamls, e.g.: 
<https://github.com/apache/incubator-ariatosca/blob/master/tests/resources/service-templates/tosca-simple-1.0/node-cellar/inputs.yaml>

I think if it's adding a license header to these files is not required, then 
we're better off without it, since it's a bit cumbersome for the CLI 
configuration file or a one-liner inputs file - But we can definitely add the 
license header if you think we should or if I misunderstood and they are in 
fact required there.


<@U4SCXA5DL> , if you do still want to add them, do you want to add the license 
header to the rest of the yaml files as part of this PR as well, and remove the 
yaml rule from rat-excludes?
undefined: 3) Regarding PR process and discussion - Completely agree with 
summarizing discussions that take place face-to-face or over phone on the 
mailing list - though I do think for the most part we have indeed made review 
comments either on Github (which should be copied to the mailing lists) or over 
Slack.
Do you think any further steps are required to ensure that the discussions over 
PRs are 100% public, e.g. a voting thread on each PR or so? To be honest I'm 
not really sure how this is done in other small incubation projects, so I'm 
personally open to any suggestions really
 4) Finally, thanks for everyone who voted! And (soon-to-be-)congrats to all of 
us :slightly_smiling_face:
undefined: <@U5416JV9R> i already added them to all of yaml files
 i’ll remove the yaml rule from rat-exclude
 know what, i actually agree with u that u don’t need license files in yaml
 i’ll close that PR and mark A-300 as ‘Won’t Fix’
undefined: :thumbsup: :slightly_smiling_face:
undefined: they’re example files?
undefined: yeah example files - and its not worth it adding license headers to 
yaml
 closing that PR und marking A-300 as ‘Won’t Fix’
undefined: done :point_up:
undefined: can examples be moved into their own repo?
undefined: <@U4RAXBZ1Q> i think there is a bigger question of creating a 
"manual" of sorts for using aria, which would include examples in context. 
right now these are more at a "hello world" level. also note they are part of 
the source distribution, not the release.
undefined: <@U5416JV9R> i closed A-300, u may want to respond to Justin on dev@ 
and clarify as to why the examples/*.yml don’t need a license header


Reply via email to