Hello,
Am 26.03.2017 um 23:21 schrieb Wolfgang Mauerer:
Am 24/03/2017 um 20:10 schrieb Stefan Kuppelwieser:I have tried it with an empty list of revision [1] and it works.
after I run the qemu example I want create two new example for thethat's indeed an under-documented edge of codeface. Basically,
repository ansible[1] and puppet[2].
I create following file structure the new analysis
|-/vagrant (folder)/
|-- analysis_example_ansible.sh
|-- analysis_example_puppet.sh
|---/conf (folder)/
|---- ansible.conf
|---- puppet.conf
After I found no documentation to create a new analysis, I used the
example as a template.
to perform a time-resolved analysis, we have to flatten the revision
graph of a project, and then traverse it. This can either be
done by specifying a list of key releases along which the history should
be traversed, or by specifying no revisions at all, in which case
the commits are ordered by time, and the list of commits is
traversed in six-month intervals. As the qemu example shows,
we can also include release candidate versions; a time interval is then
composed of three dates:
[start, rc, end]
where rc must lie within [start, end], and denotes the first release
candidate version in a development cycle. The RCs should usually
not be specified as part of the revisions list, because they are not
full releases.
Using explicit tags works well for well-tended projects, or when the
regularity of cutting releases and the comparability of different
development cycles is of interest. When the release structure is
irregular (which I assume from a cursory glance at puppet and
ansible is the case for these), I would use time-based analysis. Just
specify an empty list of revisions and rcs in your config file,
and codeface will automatically segment the development history into
intervals.
To obtain information about the social cooperation between contributors,03:08:00.283 Loading required package: NLP
we need to analyse who has collaborated with whom, and there are
multiple ways how to approach this. Usually, either tag or
proximity is appropriate. The former relies on the presence
of DCO tags (Signed-off-by, Reviewed-by etc.) in the commit message.
Since neither ansible nor puppet use these consistently (some puppet
contributors seem to use Signed-off-by on occasion, but since the
practise is not generally established in the project, this won't
give us a proper collaboraton graph), we need to resort to proximity
mode. This elicits social interaction by determining who worked
with whom in the sense of "which developers modified the same function".
The errors you report should indeed be handled more gracefully by
codeface, but we would need to dig more into what happens in
the specific cases. Since the analysis mode you've copied from the qemu
example is not really applicable to puppet and ansible, I would
suggest that you first try to perform a time-based proximity analysis.
Thanks & best regards, Wolfgang Mauerer
The Ansible and Puppet analyse works only restricted.
This means, I can not add all git reversions (ansible[3], puppet[4]) to
the .conf , because it runs into an error during the analyse of the commits.
For example you can see the puppet failure in the log [5].
I have used following configuration [6].
I have already found out if on a tag x.x.x a tag x.x.xx follows it runs
into a traceback error. (Only by the puppet analyse)
For example [4] in the line 88 - 102.
In cause of this, I tried the puppet analyse with a modifcated
puppet.conf [7] and it run through, but I do not think this should be
the right way.
For ansible it works restricted.
That means, that I modificated the reversions list in the .conf.
I have removed one tag, and it run through, but I do not think this
should be the right way, too.
With this configuration it works [9]. I have removed line 3 from [3].
[1]: https://github.com/ansible/ansible.git
[2]: https://github.com/puppetlabs/puppet.git
[3]: Attachment -> Git-Tag-ansible.txt
[4]: Attachment -> Git-Tag-puppet.txt
[5]: Attachment -> puppet-fail.conf
[6]: Attachment -> analysis_example_puppet.sh and puppet-fail.conf
[7]: Attachment -> puppet-modifcated.conf
[9]:
https://github.com/StefanKuppelwieser/Codefacee-analysis/blob/master/conf/ansible.conf
Best regards,
Stefan Kuppelwieser
Attachment:
puppetOverview.PNG
Description: PNG image
Attachment:
JavaScriptErrorConsole.PNG
Description: PNG image
