incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: Presentation and Metrics work in Allura
Date Fri, 13 Jul 2012 02:31:18 GMT
On Wed, Jul 11, 2012 at 4:07 AM, Alvaro del Castillo <>wrote:

> Hi guys,
> My name is Alvaro del Castillo and I work as a software engineer in
> Bitergia company (
Hi Alvaro!

> First of all, thank you for Allura. It is a very nice piece of software,
> with a solid and recent architecture, based in Python so very agile to
> develop with it, so modular and last but not least, Open Source!
> Bitergia company is specialized in metrics in software projects. It is a
> very young company. And we are working close with Allura for some months
> now. We think that the best place to integrate our software metrics is
> inside forges so it has been a very natural decision, because Bitergia
> is an Open Source soul company.
> We have some experience with Fusion Forge but when we discover Allura
> the adoption of it was a natural choice.

Great :D

> In our first prototype for creating metrics inside Allura we hace
> created a new module for Allura (AlluraBitergiaMetrics is the actual
> name, but probably we should change it) for displaying metrics. We have
> an Allura server with the module deployed at:
That looks very nice.

> It is just a first try of the technology and possibilities. And now it
> is time to define next steps, cleanup code and work with Allura
> community in order to decide the best way to implement things.
> The source code for the module is in:
I've looked at the code briefly, but rather than read through all of it,
perhaps you can inform me.  How do you gather the data for the reports?
 There is repository refresh code that is triggered after each commit.
 Does it hook into that?  Would it be useful to do so?

What about scalability?  For us at SourceForge, we have hundreds of
thousands of projects, so it is of some concern to us.

> I need to remove some testing code.
> So next steps, how do you see this initiative? do you find interesting
> including this kind of information in the forge? Is it the best way to
> create a new module for Allura?

Of course the nice thing about Allura is that the tools/apps can be
independent, like you have developed AlluraBitergiaMetrics already.  This
does seem like it would be something nice to integrate into the core SCM
tools (git/hg/svn) that come with Allura.

At SourceForge we have some SCM statistics in our legacy system (e.g.
for which we would like to have an equivalent in Allura, at some point.
 Actually the recording of the SCM activity is in our legacy system, but
the stats system is independent.  We use Zarkov for these stats and others on
SourceForge.  So we would likely implement something in Allura that works
with Zarkov.

Anyway, the types of stats you have here are beyond that, and could be in
addition to anything we implement for our legacy data.  Both could be

If a new feature like this were to be added to the core tools, it would be
best controlled by a configuration option to enable it or not.  We do this
for some of our features (e.g. Zarkov is not a required dependency for
Allura).  Config flags are very useful so that different deployments of
Allura can control whether or not they want to use a feature.  We have also
learned (the hard way) that it is useful during development so that
something new can be added to Allura if it has basic functionality but is
not ready to be enabled in production.  That keeps the code in sync with
the main 'dev' branch.  Having tons of work in a branch until it is
completely polished and done is likely to have conflicts and merge issues.
 A config flag is better.


Dave Brondsema
Principal Software Engineer -

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message