For us at SourceForge, we have a need to build a feature that lets project
admins download a backup/export of all their project data.  Since this is a
pretty big feature, I wanted to propose here how we might do it and get feedback
& ideas before we proceed.

Add a bulk_export() method to Application which would be responsible for
generating json for all the artifacts in the tool.  The format should match the
API format for artifacts so that we're consistent.  Thus any tool that
implements bulk_export() would typically loop through all the artifacts for this
instance (matching app_config_id) and convert to json the same way the API json
is generated (e.g. call the __json__ method or RestController method; some
refactoring might be needed).  Multiple types of artifacts/objects could be
listed out in groups, e.g. Tracker app could have a list of tickets, list of
saved search bins, list of milestones, and the tracker config data.  Discussion
threads would need to be included too, ideally inline with the artifact they go
with.  No permission checks would be done since this export would only be
available to admins (makes it faster & simpler).

Provide a page on the Admin sidebar to generate a bulk export.  Project admins
could choose individual tool instances, or all tools in the project (that
support it).  That form would kick off a background task which goes through the
selected tools and runs their bulk_export() methods.  Save each tool's data as
mount_point.json and zip them all together.

It'd be easiest to store & deliver the zip files similarly to the code snapshots
(static files not served through allura), but that won't be secure.  We'll need
to either serve it through allura with authentication, or maybe name the zip
file with a random name that can't be guessed (and then serve it directly
through apache or nginx).  Other ideas?

When the task is complete, notify the user.  What way is best?  Send an email?
Probably would be good to show a listing of available completed extracts on the
extract page, so if any older ones are still sitting around they can be
retrieved (would be up to server admins to have a cron to delete old files)

We could make this something that can be triggered automatically via the API and
check status through the API, but that seems like a good thing to add on later.

Should we include attachments?  These would be important in some cases but not
in others.  It could also increase the export size immensely in some cases.
Maybe leave out for now, and add in later when needed, possibly as an option.

Further thoughts on implementation details:

So that a giant json string doesn't have to be held in memory for each tool, the
export task should open a file handle for mount_point.json and send call
bulk_export() with that open file handle and each App can append to their file
incrementally.

If mongo performance is slow, some refactoring may be needed to avoid lots of
individual mongo calls and be more batch oriented.  We can see how it goes.

Could parallelize bulk_export() later, to do multiple tools at once.


Sound reasonable?  Any suggestions or other ideas?


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

We've added a new step to the Allura build process to generate and publish API docs. What we
have so far is here: 

http://allura.sourceforge.net/docs/#api-documentation

With this first round of API docs we tried to cover the key components needed to build an
Allura plugin. Couple these docs with an example standalone plugin (http://sf.net/p/forgepastebin
is a good one), and hopefully you'll have enough info to start creating your own Allura plugin.


This is just a start! We'll be gradually improving and adding to the Allura documentation
as we move forward.

-- 
Tim Van Steenburgh

Dear podling,

This email was sent by an automated system on behalf of the Apache Incubator PMC.
It is an initial reminder to give you plenty of time to prepare your quarterly
board report.

The board meeting is scheduled for Wed, 19 June 2013, 10:30:00:00 PST. The report 
for your podling will form a part of the Incubator PMC report. The Incubator PMC 
requires your report to be submitted 2 weeks before the board meeting, to allow 
sufficient time for review and submission (Wed, Jun 5th).

Please submit your report with sufficient time to allow the incubator PMC, and 
subsequently board members to review and digest. Again, the very latest you 
should submit your report is 2 weeks prior to the board meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report
----------------------

Your report should contain the following:

 * Your project name
 * A brief description of your project, which assumes no knowledge of the project
   or necessarily of its field
 * A list of the three most important issues to address in the move towards 
   graduation.
 * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of
 * How has the community developed since the last report
 * How has the project developed since the last report.
 
This should be appended to the Incubator Wiki page at:

  http://wiki.apache.org/incubator/June2013

Note: This manually populated. You may need to wait a little before this page is
      created from a template.

Mentors
-------
Mentors should review reports for their project(s) and sign them off on the 
Incubator wiki page. Signing off reports shows that you are following the 
project - projects that are not signed may raise alarms for the Incubator PMC.

Incubator PMC

BACKUPS 

I made a cron to do a `mongodump` daily. There a ticket for INFRA (https://issues.apache.org/jira/browse/INFRA-6360)
to encrypt the daily backup and ship offsite.

SSL & EMAIL

Ticketed for INFRA: 
https://issues.apache.org/jira/browse/INFRA-6359
https://issues.apache.org/jira/browse/INFRA-6361

SCM

Repo root on the vm is /var/local/repos. I installed a Git tool in the Allura project, then
added it as the 'local' remote on the vm's checkout of git-wip-us.a.o. There's a cron that
pulls master from git-wip-us.a.o and pushes it to the 'local' remote and triggers a refresh
every 5 minutes.

SOLR

Didn't realize this was never set up before. Got it set up (v4.2.1) and running.


Next steps are to follow-up with infra on the tickets listed above. 

-- 
Tim Van Steenburgh

On 06/04/2013 04:38 PM, Roberto Galoppini wrote:
> On Tue, Jun 4, 2013 at 8:35 PM, Dave Brondsema <dave@brondsema.net> wrote:
>> I've drafted a report for us at http://wiki.apache.org/incubator/June2013  Did I
>> miss anything we've accomplished?  Feel free to edit it or sign-off if ready.
> 
> I believe it worth to notice that we have people from the PROSE
> EU-funded projects joined us to implement Allura on-premise, and even
> if the site is still in beta it looks really nice:
> http://opensourceprojects.eu/
> 

I've added this to the report.  Thanks.

> Last but not least we might want to mention that Stefano and Simone
> graduated with their thesis based on the experience maturated at the
> Apache Allura podling. I wish to congratulate with them for the great
> job, as witnessed by the fact they got an extra mark (a very rare
> thing at Politecnico of Milan!).

Great, congrats to Simone and Stefano!  Are there any public papers or
such from the thesis work?

> 
> Roberto
> 
> 
>>
>> For reference, our last report was at http://wiki.apache.org/incubator/March2013
>>
>>
>> On 5/31/13 8:13 PM, Marvin wrote:
>>> Dear podling,
>>>
>>> This email was sent by an automated system on behalf of the Apache Incubator
PMC.
>>> It is an initial reminder to give you plenty of time to prepare your quarterly
>>> board report.
>>>
>>> The board meeting is scheduled for Wed, 19 June 2013, 10:30:00:00 PST. The report
>>> for your podling will form a part of the Incubator PMC report. The Incubator
PMC
>>> requires your report to be submitted 2 weeks before the board meeting, to allow
>>> sufficient time for review and submission (Wed, Jun 5th).
>>>
>>> Please submit your report with sufficient time to allow the incubator PMC, and
>>> subsequently board members to review and digest. Again, the very latest you
>>> should submit your report is 2 weeks prior to the board meeting.
>>>
>>> Thanks,
>>>
>>> The Apache Incubator PMC
>>>
>>> Submitting your Report
>>> ----------------------
>>>
>>> Your report should contain the following:
>>>
>>>  * Your project name
>>>  * A brief description of your project, which assumes no knowledge of the project
>>>    or necessarily of its field
>>>  * A list of the three most important issues to address in the move towards
>>>    graduation.
>>>  * Any issues that the Incubator PMC or ASF Board might wish/need to be aware
of
>>>  * How has the community developed since the last report
>>>  * How has the project developed since the last report.
>>>
>>> This should be appended to the Incubator Wiki page at:
>>>
>>>   http://wiki.apache.org/incubator/June2013
>>>
>>> Note: This manually populated. You may need to wait a little before this page
is
>>>       created from a template.
>>>
>>> Mentors
>>> -------
>>> Mentors should review reports for their project(s) and sign them off on the
>>> Incubator wiki page. Signing off reports shows that you are following the
>>> project - projects that are not signed may raise alarms for the Incubator PMC.
>>>
>>> Incubator PMC
>>>
>>
>>
>>
>> --
>> Dave Brondsema : dave@brondsema.net
>> http://www.brondsema.net : personal
>> http://www.splike.com : programming
>>               <><
> 


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
               <><

E.g. https://sourceforge.net/p/strawhat/discussion/general

The "Update email subscriptions" button doesn't seem to be tied in any way
to the actual email notifications implemented via Mailbox, AFAICT.

Would it make more sense to remove that button and the associated
checkboxes and fix the standard subscription control on individual thread
pages (as mentioned in https://sourceforge.net/p/allura/tickets/5461/), or
does un/subscribing to multiple threads at once seem like a useful feature?

On Tue, Jun 4, 2013 at 8:35 PM, Dave Brondsema <dave@brondsema.net> wrote:
> I've drafted a report for us at http://wiki.apache.org/incubator/June2013  Did I
> miss anything we've accomplished?  Feel free to edit it or sign-off if ready.

I believe it worth to notice that we have people from the PROSE
EU-funded projects joined us to implement Allura on-premise, and even
if the site is still in beta it looks really nice:
http://opensourceprojects.eu/

Last but not least we might want to mention that Stefano and Simone
graduated with their thesis based on the experience maturated at the
Apache Allura podling. I wish to congratulate with them for the great
job, as witnessed by the fact they got an extra mark (a very rare
thing at Politecnico of Milan!).

Roberto


>
> For reference, our last report was at http://wiki.apache.org/incubator/March2013
>
>
> On 5/31/13 8:13 PM, Marvin wrote:
>> Dear podling,
>>
>> This email was sent by an automated system on behalf of the Apache Incubator PMC.
>> It is an initial reminder to give you plenty of time to prepare your quarterly
>> board report.
>>
>> The board meeting is scheduled for Wed, 19 June 2013, 10:30:00:00 PST. The report
>> for your podling will form a part of the Incubator PMC report. The Incubator PMC
>> requires your report to be submitted 2 weeks before the board meeting, to allow
>> sufficient time for review and submission (Wed, Jun 5th).
>>
>> Please submit your report with sufficient time to allow the incubator PMC, and
>> subsequently board members to review and digest. Again, the very latest you
>> should submit your report is 2 weeks prior to the board meeting.
>>
>> Thanks,
>>
>> The Apache Incubator PMC
>>
>> Submitting your Report
>> ----------------------
>>
>> Your report should contain the following:
>>
>>  * Your project name
>>  * A brief description of your project, which assumes no knowledge of the project
>>    or necessarily of its field
>>  * A list of the three most important issues to address in the move towards
>>    graduation.
>>  * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of
>>  * How has the community developed since the last report
>>  * How has the project developed since the last report.
>>
>> This should be appended to the Incubator Wiki page at:
>>
>>   http://wiki.apache.org/incubator/June2013
>>
>> Note: This manually populated. You may need to wait a little before this page is
>>       created from a template.
>>
>> Mentors
>> -------
>> Mentors should review reports for their project(s) and sign them off on the
>> Incubator wiki page. Signing off reports shows that you are following the
>> project - projects that are not signed may raise alarms for the Incubator PMC.
>>
>> Incubator PMC
>>
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><

I've drafted a report for us at http://wiki.apache.org/incubator/June2013  Did I
miss anything we've accomplished?  Feel free to edit it or sign-off if ready.

For reference, our last report was at http://wiki.apache.org/incubator/March2013


On 5/31/13 8:13 PM, Marvin wrote:
> Dear podling,
> 
> This email was sent by an automated system on behalf of the Apache Incubator PMC.
> It is an initial reminder to give you plenty of time to prepare your quarterly
> board report.
> 
> The board meeting is scheduled for Wed, 19 June 2013, 10:30:00:00 PST. The report 
> for your podling will form a part of the Incubator PMC report. The Incubator PMC 
> requires your report to be submitted 2 weeks before the board meeting, to allow 
> sufficient time for review and submission (Wed, Jun 5th).
> 
> Please submit your report with sufficient time to allow the incubator PMC, and 
> subsequently board members to review and digest. Again, the very latest you 
> should submit your report is 2 weeks prior to the board meeting.
> 
> Thanks,
> 
> The Apache Incubator PMC
> 
> Submitting your Report
> ----------------------
> 
> Your report should contain the following:
> 
>  * Your project name
>  * A brief description of your project, which assumes no knowledge of the project
>    or necessarily of its field
>  * A list of the three most important issues to address in the move towards 
>    graduation.
>  * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of
>  * How has the community developed since the last report
>  * How has the project developed since the last report.
>  
> This should be appended to the Incubator Wiki page at:
> 
>   http://wiki.apache.org/incubator/June2013
> 
> Note: This manually populated. You may need to wait a little before this page is
>       created from a template.
> 
> Mentors
> -------
> Mentors should review reports for their project(s) and sign them off on the 
> Incubator wiki page. Signing off reports shows that you are following the 
> project - projects that are not signed may raise alarms for the Incubator PMC.
> 
> Incubator PMC
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

On 5/31/13 10:15 PM, Rich Bowen wrote:
> It would be wonderful if we could get a realease out, or at least in
> process, for this report. Where are we in that process?
> 

I think we're all set with licensing (to our own knowledge) and just need to cut
the release, vote on it, etc.


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

It would be wonderful if we could get a realease out, or at least in
process, for this report. Where are we in that process?

-- 
Rich Bowen, mobile edition
rbowen@rcbowen.com
On May 31, 2013 10:12 PM, "Marvin" <no-reply@apache.org> wrote:

>
>
> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC.
> It is an initial reminder to give you plenty of time to prepare your
> quarterly
> board report.
>
> The board meeting is scheduled for Wed, 19 June 2013, 10:30:00:00 PST. The
> report
> for your podling will form a part of the Incubator PMC report. The
> Incubator PMC
> requires your report to be submitted 2 weeks before the board meeting, to
> allow
> sufficient time for review and submission (Wed, Jun 5th).
>
> Please submit your report with sufficient time to allow the incubator PMC,
> and
> subsequently board members to review and digest. Again, the very latest you
> should submit your report is 2 weeks prior to the board meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
> ----------------------
>
> Your report should contain the following:
>
>  * Your project name
>  * A brief description of your project, which assumes no knowledge of the
> project
>    or necessarily of its field
>  * A list of the three most important issues to address in the move towards
>    graduation.
>  * Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
>  * How has the community developed since the last report
>  * How has the project developed since the last report.
>
> This should be appended to the Incubator Wiki page at:
>
>   http://wiki.apache.org/incubator/June2013
>
> Note: This manually populated. You may need to wait a little before this
> page is
>       created from a template.
>
> Mentors
> -------
> Mentors should review reports for their project(s) and sign them off on the
> Incubator wiki page. Signing off reports shows that you are following the
> project - projects that are not signed may raise alarms for the Incubator
> PMC.
>
> Incubator PMC
>
>

Dear podling,

This email was sent by an automated system on behalf of the Apache Incubator PMC.
It is an initial reminder to give you plenty of time to prepare your quarterly
board report.

The board meeting is scheduled for Wed, 19 June 2013, 10:30:00:00 PST. The report 
for your podling will form a part of the Incubator PMC report. The Incubator PMC 
requires your report to be submitted 2 weeks before the board meeting, to allow 
sufficient time for review and submission (Wed, Jun 5th).

Please submit your report with sufficient time to allow the incubator PMC, and 
subsequently board members to review and digest. Again, the very latest you 
should submit your report is 2 weeks prior to the board meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report
----------------------

Your report should contain the following:

 * Your project name
 * A brief description of your project, which assumes no knowledge of the project
   or necessarily of its field
 * A list of the three most important issues to address in the move towards 
   graduation.
 * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of
 * How has the community developed since the last report
 * How has the project developed since the last report.
 
This should be appended to the Incubator Wiki page at:

  http://wiki.apache.org/incubator/June2013

Note: This manually populated. You may need to wait a little before this page is
      created from a template.

Mentors
-------
Mentors should review reports for their project(s) and sign them off on the 
Incubator wiki page. Signing off reports shows that you are following the 
project - projects that are not signed may raise alarms for the Incubator PMC.

Incubator PMC

On 05/23/2013 05:35 PM, Cory Johns wrote:
> Does anyone object to me removing the commit counts on the branch & tag
> buttons in the sidebar?  They can be expensive to compute and I don't feel
> they add much value.

Nope, no objections here. Especially with large repos the numbers don't
even fit.  I think there is some small value on smaller repos when e.g.
one branch has 12 commits and another has 16, you can see that it's
*probably* 4 commits ahead.  But not worth it given the computation cost
you describe

> They're currently cached as part of the reindexing process, but I'd like to
> move away from that as much as possible, since it's been such a huge source
> of issues.  If we really want the counts back at some point, we could
> potentially load them as AJAX or cache them in memcached, but I'd prefer to
> defer that if we even want to bother.
> 


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
               <><

On 5/23/13 5:10 PM, Peter Hartmann wrote:
> On 23.05.2013 21:56, Dave Brondsema wrote:
>> To help us move along towards the release, I ran the Release Audit Tool again
>> and fixed up some missing headers and added .  They were pretty trivial changes
>> so I did them on master, they can be reviewed here in case I did anything wrong:
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab
>>
>>
>> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898
>>
>>
>> After that, I was left with just one file without license info:
>> Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do with that.
>> It looks like it was sourced from somewhere else and I couldn't find a license
>> for it.  But it's just test data, so maybe it doesn't need a license, or maybe
>> we can remove the test that uses it.  Thoughts?
> Hey Dave. I had a real tough week, so I haven't really made much work on that.
> My apologies.
> 
> I did some heavy research on that file while doing a set-up for RAT and initial
> audit. In fact, one software package has removed it, due to the statement on
> author's website:
> http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/utf8/utf-8-demo.txt
> 
> 
> However, the file is distributed along with an Unicode fonts set, and here's
> what author has to say about it:
> 
>> The copyright status of these fonts remains the same as for the original fonts
> in the X11 distribution
> 
> http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
> 
> And the fonts are under public domain (copyright information is available in
> each individual .bdf file). As per ASF guidelines, public domain is handled by
> adding an attribution line to NOTICE. Don't really know why I haven't done it
> back then.
> 

Cool, good info.  If we want to keep it simple, we could remove it pretty easily
too.  It's only used one test, in Allura/allura/tests/test_helpers.py  We could
easily test with simpler file that we create

And FYI, I ran 'rat' on another server recently (our internal CI build) and it
thought unicode_test.txt was binary.


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Does anyone object to me removing the commit counts on the branch & tag
buttons in the sidebar?  They can be expensive to compute and I don't feel
they add much value.

They're currently cached as part of the reindexing process, but I'd like to
move away from that as much as possible, since it's been such a huge source
of issues.  If we really want the counts back at some point, we could
potentially load them as AJAX or cache them in memcached, but I'd prefer to
defer that if we even want to bother.

On 23.05.2013 21:56, Dave Brondsema wrote:
> To help us move along towards the release, I ran the Release Audit Tool again
> and fixed up some missing headers and added .  They were pretty trivial changes
> so I did them on master, they can be reviewed here in case I did anything wrong:
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898
>
> After that, I was left with just one file without license info:
> Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do with that.
> It looks like it was sourced from somewhere else and I couldn't find a license
> for it.  But it's just test data, so maybe it doesn't need a license, or maybe
> we can remove the test that uses it.  Thoughts?
Hey Dave. I had a real tough week, so I haven't really made much work on 
that. My apologies.

I did some heavy research on that file while doing a set-up for RAT and 
initial audit. In fact, one software package has removed it, due to the 
statement on author's website: 
http://source.icu-project.org/repos/icu/icu/trunk/source/extra/uconv/samples/utf8/utf-8-demo.txt

However, the file is distributed along with an Unicode fonts set, and 
here's what author has to say about it:

 > The copyright status of these fonts remains the same as for the 
original fonts in the X11 distribution

http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html

And the fonts are under public domain (copyright information is 
available in each individual .bdf file). As per ASF guidelines, public 
domain is handled by adding an attribution line to NOTICE. Don't really 
know why I haven't done it back then.

To help us move along towards the release, I ran the Release Audit Tool again
and fixed up some missing headers and added .  They were pretty trivial changes
so I did them on master, they can be reviewed here in case I did anything wrong:

https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=6702bc7bf1ff2ba53daf2fbe05bf1357217508ab

https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commit;h=53d8b05c2e35ef00123703e8da8f71d9c605a898

After that, I was left with just one file without license info:
Allura/allura/tests/data/unicode_test.txt  I wasn't sure what to do with that.
It looks like it was sourced from somewhere else and I couldn't find a license
for it.  But it's just test data, so maybe it doesn't need a license, or maybe
we can remove the test that uses it.  Thoughts?

On 5/8/13 1:41 PM, Peter Hartmann wrote:
> W dniu 08.05.2013 16:58, Dave Brondsema pisze:
>> I wonder if maybe we should do a simple first release (e.g. tarball of the whole
>> thing, if that's the easiest option).  Then we could get our first release out
>> sooner.  We can also work through any licensing/procedure concerns on the first
>> release(s) and not have to worry about technical complexities at the same time.
> I sort of agree. Also, I was going to mention that later, but it seems to me now
> that "codebase tarball" would be better way to do things because as far as i
> know, tests are typically omitted from pypi packages.Tim was right again :)
> 
> One problem I can see is that Allura doesn't seem too portable. I fixed some
> related errors occuring on my distro (Arch Linux) but this may only be tip of an
> iceberg.Well, it's not like we'll know unless we get more people using it :P
> 
> If it is possible, i'd recommend to mark this release as alpha or beta. As a
> user I'd be surprised to find that stable release only works on a specified
> setup of Ubuntu.
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Hey everyone,

There's a new vagrant box available for Allura. Changes include:

- Mongodb upgraded to v2.2.3
- Solr upgraded to v4.2.1
- matplotlib and numpy dependencies removed

The instructions for getting started are here: https://sourceforge.net/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/

Tim

FYI we had an open ticket https://issues.apache.org/jira/browse/INFRA-6066 about
a several issues for our Allura instance.  We're going to start a thread on
infrastructure@a.o shortly, if anybody wants to tune in.

-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

It looks like the tests are expecting ForgeActivity to be installed. Try running ./update.sh
first, then run the tests again.

Tim

Sent from my iPhone

On May 20, 2013, at 4:58 AM, Edit Mera <emera@donay.com> wrote:

> Yes, it is strange the number of failures > number of tests for the
> ForgeTracker tool. For other tools this does not happen.
> So my question is: do I have to do anything else besides what is described
> here http://sourceforge.net/p/allura/git/ci/master/tree/README.markdown to
> make the existing tests pass (for Allura and other Allura tools which come
> with it) ?
> Did I run the tests correctly: "ALLURA_VALIDATION=none ./run_tests" for
> Allura
> and "python setup.py nosetests" for ForgeTracker/ForgeWiki tools?
> 
> 
> 
> 
> On Fri, May 17, 2013 at 9:30 PM, Olemis Lang <olemis@gmail.com> wrote:
> 
>> On 5/17/13, Olemis Lang <olemis@gmail.com> wrote:
>>> On 5/17/13, Edit Mera <emera@donay.com> wrote:
>>>> Hi,
>>> 
>>> :)
>>> 
>>> [...]
>>>> 
>>>> ----------------------------------------------------------------------
>>>> Ran 105 tests in 34.943s
>>>> 
>>>> FAILED (errors=108)
>>>> 
>>>> What could be the problem? How can I make these tests pass?
>>> 
>>> That's lokking something weird . Test failures > Total tests ? Is it a
>>> big in unittest module ?
>> 
>> big => bug ... sorry ...
>> :-$
>> 
>> --
>> Regards,
>> 
>> Olemis.
>> 
>> Apache™ Bloodhound contributor
>> http://issues.apache.org/bloodhound
>> 
>> Blog ES: http://simelo-es.blogspot.com/
>> Blog EN: http://simelo-en.blogspot.com/
>> 
>> Featured article:
>> 

Yes, it is strange the number of failures > number of tests for the
ForgeTracker tool. For other tools this does not happen.
So my question is: do I have to do anything else besides what is described
here http://sourceforge.net/p/allura/git/ci/master/tree/README.markdown to
make the existing tests pass (for Allura and other Allura tools which come
with it) ?
Did I run the tests correctly: "ALLURA_VALIDATION=none ./run_tests" for
Allura
and "python setup.py nosetests" for ForgeTracker/ForgeWiki tools?




On Fri, May 17, 2013 at 9:30 PM, Olemis Lang <olemis@gmail.com> wrote:

> On 5/17/13, Olemis Lang <olemis@gmail.com> wrote:
> > On 5/17/13, Edit Mera <emera@donay.com> wrote:
> >> Hi,
> >>
> >
> > :)
> >
> > [...]
> >>
> >> ----------------------------------------------------------------------
> >> Ran 105 tests in 34.943s
> >>
> >> FAILED (errors=108)
> >>
> >> What could be the problem? How can I make these tests pass?
> >>
> >
> > That's lokking something weird . Test failures > Total tests ? Is it a
> > big in unittest module ?
> >
>
> big => bug ... sorry ...
> :-$
>
> --
> Regards,
>
> Olemis.
>
> Apache™ Bloodhound contributor
> http://issues.apache.org/bloodhound
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

On 5/17/13, Olemis Lang <olemis@gmail.com> wrote:
> On 5/17/13, Edit Mera <emera@donay.com> wrote:
>> Hi,
>>
>
> :)
>
> [...]
>>
>> ----------------------------------------------------------------------
>> Ran 105 tests in 34.943s
>>
>> FAILED (errors=108)
>>
>> What could be the problem? How can I make these tests pass?
>>
>
> That's lokking something weird . Test failures > Total tests ? Is it a
> big in unittest module ?
>

big => bug ... sorry ...
:-$

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

On 5/17/13, Edit Mera <emera@donay.com> wrote:
> Hi,
>

:)

[...]
>
> ----------------------------------------------------------------------
> Ran 105 tests in 34.943s
>
> FAILED (errors=108)
>
> What could be the problem? How can I make these tests pass?
>

That's lokking something weird . Test failures > Total tests ? Is it a
big in unittest module ?

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Hi,

I have installed Allura as described here
http://sourceforge.net/p/allura/git/ci/master/tree/README.markdown.
I have written a new tool for Allura and I want to write some tests.
The problem is that the Allura tests fail (ALLURA_VALIDATION=none
./run_tests) and if I run "python setup.py nosetests" for a tool such as
ForgeTracker, tests fail as well.
The test.log does not contain any error messages. In console I have
messages like:
...

======================================================================
ERROR: test suite for <module 'forgetracker.tests.test_tracker_roles'
from '/root/src/allura/ForgeTracker/forgetracker/tests/test_tracker_roles.pyc'>
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/anvil/local/lib/python2.7/site-packages/nose/suite.py",
line 208, in run
    self.setUp()
  File "/root/anvil/local/lib/python2.7/site-packages/nose/suite.py",
line 291, in setUp
    self.setupContext(ancestor)
  File "/root/anvil/local/lib/python2.7/site-packages/nose/suite.py",
line 314, in setupContext
    try_run(context, names)
  File "/root/anvil/local/lib/python2.7/site-packages/nose/util.py",
line 478, in try_run
    return func()
  File "/root/src/allura/ForgeTracker/forgetracker/tests/test_tracker_roles.py",
line 26, in setUp
    setup_basic_test()
  File "/root/src/allura/AlluraTesting/alluratest/controller.py", line
66, in setup_basic_test
    cmd.run([test_file])
  File "/root/anvil/local/lib/python2.7/site-packages/paste/script/appinstall.py",
line 68, in run
    return super(AbstractInstallCommand, self).run(new_args)
  File "/root/anvil/local/lib/python2.7/site-packages/paste/script/command.py",
line 238, in run
    result = self.command()
  File "/root/anvil/local/lib/python2.7/site-packages/paste/script/appinstall.py",
line 456, in command
    self, config_file, section, self.sysconfig_install_vars(installer))
  File "/root/anvil/local/lib/python2.7/site-packages/paste/script/appinstall.py",
line 598, in setup_config
    mod.setup_app, command, filename, section, vars)
  File "/root/anvil/local/lib/python2.7/site-packages/paste/script/appinstall.py",
line 614, in _call_setup_app
    func(command, conf, vars)
  File "/root/src/allura/Allura/allura/websetup/__init__.py", line 37,
in setup_app
    bootstrap.bootstrap(command, conf, vars)
  File "/root/src/allura/Allura/allura/websetup/bootstrap.py", line
166, in bootstrap
    p_adobe1 = n_adobe.register_project('adobe-1', u_admin)
  File "/root/src/allura/Allura/allura/model/neighborhood.py", line
121, in register_project
    self, shortname, project_name, user or getattr(c, 'user', None),
user_project, private_project, apps)
  File "/root/src/allura/Allura/allura/lib/plugin.py", line 441, in
register_project
    return self._create_project(neighborhood, shortname, project_name,
user, user_project, private_project, apps)
  File "/root/src/allura/Allura/allura/lib/plugin.py", line 500, in
_create_project
    apps=apps or [] if 'tools' in project_template else None)
  File "/root/src/allura/Allura/allura/model/project.py", line 764, in
configure_project
    self.install_app(ep_name, mount_point, label, ordinal=i)
  File "/root/src/allura/Allura/allura/model/project.py", line 555, in
install_app
    App = g.entry_points['tool'][ep_name]
  File "/root/src/allura/Allura/allura/lib/utils.py", line 365, in __getitem__
    return self.store[self.__keytransform__(key)]
KeyError: 'activity'

----------------------------------------------------------------------
Ran 105 tests in 34.943s

FAILED (errors=108)



What could be the problem? How can I make these tests pass?

Thanks.

Edit

Allura tests use /tmp for some things, like SVN repo testing.  However, on some
systems (e.g. Centos 6.3 on our new internal CI server) the /tmp filesystem is
mounted as `noexec` so nothing can execute directly on it, even if the execute
bit is set on the file.

I fixed a number of test failures with this commit
https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=commitdiff;h=97ddc1593a230fdd09f9cd65aab28a2ec31fc4ea

But now I'm facing errors that can't be easily worked around.  The trace is at
the end of this email, but basically the `pre-revprop-change` hook must exist
and be executable to run an svnsync.  So when /tmp is mounted noexec this
doesn't work.

Any suggestions for how to make our tests work better?  I'm thinking about
having them use the $TMPDIR environment variable if it is set.  In my case, I
could then set TMPDIR=/var/lib/jenkins/tmp and it should work.  But anyone else
running into this would have to know to set TMPDIR.  Another option might be use
use a local ./tmp/ directory right in the allura directory.  But I don't like
something about creating files in the local directory space (the ever-growing
test.log files are bad enough).



Traceback (most recent call last):
  File "/usr/lib64/python2.7/unittest/case.py", line 365, in run
    testMethod()
  File
"/var/lib/jenkins/workspace/allura/ForgeSVN/forgesvn/tests/model/test_repository.py",
line 152, in test_fork
    repo._impl.clone_from('file://' + repo_path)
  File "/var/lib/jenkins/workspace/allura/ForgeSVN/forgesvn/model/svn.py", line
277, in clone_from
    'initialize', self._url, source_url])
  File "/var/lib/jenkins/workspace/allura/ForgeSVN/forgesvn/model/svn.py", line
240, in check_call
    raise SVNCalledProcessError(cmd, p.returncode, stdout, stderr)
SVNCalledProcessError: Command: '['svnsync', '--non-interactive',
'--allow-non-empty', 'initialize', 'file:///tmp/testsvn',
'file:///var/lib/jenkins/workspace/allura/ForgeSVN/forgesvn/tests/data/testsvn']' returned
non-zero exit status 1
STDOUT:
STDERR: svnsync: E165001: Revprop change blocked by pre-revprop-change hook
(exit code 255) with no output.




-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Tickets (like most artifacts) are associated with a tool (a.k.a. app) instance,
not with a project directly.  This is because you can have multiple ticket tools
installed within one project.  To get the app config id(s) for a project, use
something like this:

# this is the full app_config objects:
acs = project.app_configs

# just their _id values:
ids = [ac._id for ac in project.app_configs]

# limit to Ticket tools:
ids = [ac._id for ac in project.app_configs if ac.tool_name=='Tickets']

And then you can search for tickets with a query like {"app_config_id": {"$in":
ids}}


On 5/15/13 5:43 AM, Edit Mera wrote:
> Can project be used in Ticket search?
> If not, how can I get a Ticket object in an extension tool controller
> method, knowing the ticket_num and the project?
> Or is there a way to get the ForgeTrackerApp config._id in an extension
> tool?
> Thanks in advance.
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Can project be used in Ticket search?
If not, how can I get a Ticket object in an extension tool controller
method, knowing the ticket_num and the project?
Or is there a way to get the ForgeTrackerApp config._id in an extension
tool?
Thanks in advance.

+1   Merged ph/3905 to master


On Fri, May 10, 2013 at 2:23 PM, Peter Hartmann <mailbox.tec@gmail.com>wrote:

> W dniu 10.05.2013 20:11, Dave Brondsema pisze:
>
>  Peter, on IRC you had mentioned resolving several platform-independence
>> issues.
>>   Running tests against CentOS 6.3 gives me this error and before I dig
>> into it,
>> I was wondering if this was one you had run into as well?  FWIW, we use
>> CentOS
>> 5.6 a lot and all is fine there.
>>
>>
>> FAIL: allura.tests.functional.test_**static.TestStatic.test_static_**
>> controller
>> ------------------------------**------------------------------**
>> ----------
>> Traceback (most recent call last):
>>    File
>> "/var/lib/jenkins/**shiningpanda/jobs/2756ebc1/**
>> virtualenvs/d41d8cd9/lib/**python2.7/site-packages/nose/**case.py",
>> line 197, in runTest
>>      self.test(*self.arg)
>>    File
>> "/var/lib/jenkins/workspace/**allura/Allura/allura/tests/**
>> functional/test_static.py",
>> line 23, in test_static_controller
>>      self.app.get('/nf/_static_/**wiki/js/browse.js')
>>    File
>> "/var/lib/jenkins/workspace/**allura/AlluraTesting/**alluratest/validation.py",
>> line
>> 315, in get
>>      self._validate(resp, 'get', val_params)
>>    File
>> "/var/lib/jenkins/workspace/**allura/AlluraTesting/**alluratest/validation.py",
>> line
>> 302, in _validate
>>      assert False, 'Unexpected output content type: ' + content_type
>> AssertionError: Unexpected output content type: text/javascript
>>
>>
>>
>>
>>  No, I haven't encountered that one. If you may recall, we talked on irc
> about content_type errors thrown by browser. These were releated to
> mimetype handling, but none actually happened in a test.
>
> I've pushed my branch now, as platform-independence fixes should probably
> get merged before we do Apache release (the work was done as part of
> preparing pypi release). +1?
>
>


-- 
Dave Brondsema
Principal Software Engineer - sourceforge.net
Dice Holdings, Inc.

It depends on what you want to do.  If you're just wanting to display some
information, like a banner of text, the Ticket Options page has fields for
text to display on the ticket list page and new ticket form (although not
on an existing ticket page).

You could also do something more extensive with creative use of a custom
theme.  There is some documentation here:
https://sourceforge.net/p/allura/wiki/Themes%20in%20Allura/  The theme
system is a little limited and not really aimed at replacing parts of
specific tools, but you could combine something with the header and CSS,
perhaps.

Finally, and probably closest to what you want, we have a pending
merge-request for the ability to override specific template files:
https://sourceforge.net/p/allura/git/merge-requests/4/  Unfortunately, that
has been pending for some time, and I haven't been able to get back to it
as I would have liked.  But it seems like a good starting point for what
you're looking for.  If we could get some test coverage on it and get it
cleaned up from any changes since when it was submitted, it would be nice
to get it merged in.


On Tue, May 14, 2013 at 3:53 AM, Edit Mera <emera@donay.com> wrote:

> Hi,
>
> I am building an extension tool for Allura.
> When this new extension tool is installed, I want to display some extra
> information on the ticket page.
> Is this possible? If it is, how can I customize the ticket.html template?
>
> Thanks.
> Edit
>

Hi,

I am building an extension tool for Allura.
When this new extension tool is installed, I want to display some extra
information on the ticket page.
Is this possible? If it is, how can I customize the ticket.html template?

Thanks.
Edit

So I've been setting up new continuous integration builds of our test suite,
both at https://builds.apache.org/job/Allura/ (needs some libraries installed)
and on our internal SourceForge server (where we've been running them for a while).

One feature of the tests is to validate that our HTML & JS is good.  It's not on
by default, but can be enabled with environment variable ALLURA_VALIDATION=all
before running the tests.  We have quite a few failures... I guess we haven't
run tests with this on for a while.

So if anyone is interested in cleaning those up, feel free :P  Most should be
relatively simple to fix I think.



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

W dniu 10.05.2013 20:11, Dave Brondsema pisze:
> Peter, on IRC you had mentioned resolving several platform-independence issues.
>   Running tests against CentOS 6.3 gives me this error and before I dig into it,
> I was wondering if this was one you had run into as well?  FWIW, we use CentOS
> 5.6 a lot and all is fine there.
>
>
> FAIL: allura.tests.functional.test_static.TestStatic.test_static_controller
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File
> "/var/lib/jenkins/shiningpanda/jobs/2756ebc1/virtualenvs/d41d8cd9/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
>      self.test(*self.arg)
>    File
> "/var/lib/jenkins/workspace/allura/Allura/allura/tests/functional/test_static.py",
> line 23, in test_static_controller
>      self.app.get('/nf/_static_/wiki/js/browse.js')
>    File
> "/var/lib/jenkins/workspace/allura/AlluraTesting/alluratest/validation.py", line
> 315, in get
>      self._validate(resp, 'get', val_params)
>    File
> "/var/lib/jenkins/workspace/allura/AlluraTesting/alluratest/validation.py", line
> 302, in _validate
>      assert False, 'Unexpected output content type: ' + content_type
> AssertionError: Unexpected output content type: text/javascript
>
>
>
>
No, I haven't encountered that one. If you may recall, we talked on irc 
about content_type errors thrown by browser. These were releated to 
mimetype handling, but none actually happened in a test.

I've pushed my branch now, as platform-independence fixes should 
probably get merged before we do Apache release (the work was done as 
part of preparing pypi release). +1?

Peter, on IRC you had mentioned resolving several platform-independence issues.
 Running tests against CentOS 6.3 gives me this error and before I dig into it,
I was wondering if this was one you had run into as well?  FWIW, we use CentOS
5.6 a lot and all is fine there.


FAIL: allura.tests.functional.test_static.TestStatic.test_static_controller
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/var/lib/jenkins/shiningpanda/jobs/2756ebc1/virtualenvs/d41d8cd9/lib/python2.7/site-packages/nose/case.py",
line 197, in runTest
    self.test(*self.arg)
  File
"/var/lib/jenkins/workspace/allura/Allura/allura/tests/functional/test_static.py",
line 23, in test_static_controller
    self.app.get('/nf/_static_/wiki/js/browse.js')
  File
"/var/lib/jenkins/workspace/allura/AlluraTesting/alluratest/validation.py", line
315, in get
    self._validate(resp, 'get', val_params)
  File
"/var/lib/jenkins/workspace/allura/AlluraTesting/alluratest/validation.py", line
302, in _validate
    assert False, 'Unexpected output content type: ' + content_type
AssertionError: Unexpected output content type: text/javascript




-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

I continue to get more and more frustrated with the need for a full
indexing of SCM repos in Allura and all of the complexity and performance
issues that entails.  To start to work on removing some of the dependency
on the indexing, I created a script to test the timing of generating the
tree browsing data on-demand, straight from GitPython:
https://sourceforge.net/p/allura/pastebin/518bb63d7929e51a2548196a/

Even on very large repos (linux), I'm seeing completion times almost always
under 2 seconds.  It could use some more testing on different repos, but as
it stands, it seems like we could drop this in in place of our current git
tree browsing with comparable, if not better, performance.

Looking for comments, concerns, or other feedback.


- Cory

Not all developers are visiting irc, and this should probably get 
announced anyways, so here I go :)

Apache Software Foundation's legal policy is to add a license header to 
every source file created within ASF project or donated to it:

http://www.apache.org/legal/src-headers.html

Recently, work has been taken to adopt all our codebase to this 
requirement, but our software is constantly being developed and as such, 
we need to take care of this all the time. Therefore, all developers are 
asked to add a license header, as specified in the link above, to the 
code they are contributing.

This isn't a big deal and as long as you have CLA filed, someone else 
may fix that for you later. However, by adding a header, you make it 
clear that you're willing to license your code under Apache License and 
that you yourself solidify that willingness :)

Be aware that this applies ONLY to code written under CLA, or 
contributed with clearly stated will do donate the code to ASF project 
(the latter usually happend with one-time donations, e.g. minor 
patches). Do not, under any circumstances, add license header to a 3rd 
party code, and do not replace any license headers already available in 
the 3rd party code. These sources are to be left as-is and, if they are 
licensed at all, mentioned in the LICENSE file with their license copied 
there. Read the ASF legal doc linked above, look at LICENSE and NOTICE 
files to get an impression of how it's done. When in doubt, ask here on 
the mailing list - I'm no expert but after reading a ton of ASF 
guideline documents and legal team's JIRA tickets, I may be of some 
help. And other devs may be more knowledgeable.

Cheers,
Peter

During one of our team meetings today, we discussed how to better support
and encourage the community for Allura, and the biggest item, we decided,
was being more open with our activity on the project.  To that end, I will
briefly summarize our discussion and take-aways and open it up for further
discussion here.

The discussion focused mainly on being more open with our activity on
Allura, moving discussions to the mailing list and IRC and getting ticket
activity onto the mailing list.  Rich suggested http://openhatch.org/ as a
good resource for ideas to make Allura more community-friendly, such as
tagging tickets that would be appropriate for newcomers.
http://producingoss.com/en/index.html and
https://hacks.mozilla.org/2013/05/how-to-spread-the-word-about-your-code/also
have some good information.

We also need to improve and cross-link our documentation, and get it up on
Read the Docs.  Screencasts were brought up as a great way to provide
tutorials for getting started, and having YouTube videos will increase our
organic traffic.

Our take-away goals were:
  * Send ticket notification emails to dev mailing list to increase
visibility of ticket discussion (requires #6219)
  * Get our initial release out
  * Create some sort of API / script to ease creating a merge-request from
work done on a vagrant image
  * Screencast setting up vagrant image (may require #6220)
  * Cross-link our intro docs

I'm sure I'm missing something, so please chime in with what I left out.
 Also, what other ways can we improve our interaction with the community?

W dniu 08.05.2013 16:58, Dave Brondsema pisze:
> I wonder if maybe we should do a simple first release (e.g. tarball of the whole
> thing, if that's the easiest option).  Then we could get our first release out
> sooner.  We can also work through any licensing/procedure concerns on the first
> release(s) and not have to worry about technical complexities at the same time.
I sort of agree. Also, I was going to mention that later, but it seems 
to me now that "codebase tarball" would be better way to do things 
because as far as i know, tests are typically omitted from pypi 
packages.Tim was right again :)

One problem I can see is that Allura doesn't seem too portable. I fixed 
some related errors occuring on my distro (Arch Linux) but this may only 
be tip of an iceberg.Well, it's not like we'll know unless we get more 
people using it :P

If it is possible, i'd recommend to mark this release as alpha or beta. 
As a user I'd be surprised to find that stable release only works on a 
specified setup of Ubuntu.

On 4/18/13 12:15 PM, Dave Brondsema wrote:
> So we've been working on deploying the new User Stats module onto SourceForge.
> We've had the code live for a while so it's collecting data, but haven't
> installed the tool yet to display the reports.  I ran into some performance
> problems when trying to display a report for just one user (before rolling it
> out to everyone).  I put the details in
> https://sourceforge.net/p/allura/tickets/6133/  Stefano & Simone, I wonder if
> you'd be interested in helping out with this?  We can provide more data from our
> system and try some changes if needed.
> 

Just following up for folks not watching the tickets.
https://sourceforge.net/p/allura/tickets/6133/ is closed now, also removed numpy
& matplotlib dependencies at the same time, which should make installation a bit
easier again.  More details on the ticket and suggestions from Cory about how we
could add the functionality back in if we want to.

The changes in 6133 worked, so https://sourceforge.net/u/brondsem/userstats/
loads in a reasonable amount of time now.  I did find one issue and created
https://sourceforge.net/p/allura/tickets/6212/  We'll want to fix that before
rolling this out broadly at SourceForge.


-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

I wonder if maybe we should do a simple first release (e.g. tarball of the whole
thing, if that's the easiest option).  Then we could get our first release out
sooner.  We can also work through any licensing/procedure concerns on the first
release(s) and not have to worry about technical complexities at the same time.

On 4/18/13 2:24 PM, Dave Brondsema wrote:
> From a technical standpoint, many of the packages like ForgeBlog, ForgeGit,
> ForgeTracker, etc are independent and could be packaged separately.  But I'm
> having trouble visualizing what would be in our core package.  The "Allura"
> python package can't run on its own, it is dependent on the ForgeWiki (as a
> default tool for new users).  And some top-level files and folders are needed
> too (e.g. solr_config/ and maybe requirements*.txt)  The NoWarnings and
> AlluraTesting packages are needed for running the Allura package tests too.  So
> not that it can't be done, but delivering each python package as its own tarball
> could require some effort.  I suppose that may be something we have to go
> through anyay to make pypi releases work.
> 
> Also if someone wanted to install many or all the Allura tools, it would be more
> convenient to have a whole package rather than over a dozen separate packages.
> 
> On 4/18/13 11:54 AM, Peter Hartmann wrote:
>> As part of our graduation process from Incubator, we (Allura contributors) must
>> demonstrate our ability to make an official release, in line with ASF
>> guidelines. It seems that throughout last year all technical and legal obstacles
>> have been removed and we're ready to start working on getting a release out. As
>> per https://sourceforge.net/p/allura/tickets/3905/ we also want to make a
>> release on PyPI and somehow synchronizing these two releases would be a sane
>> thing to do.
>>
>> The most basic way we may do Incubator release is simply get a repository
>> tarball on a public Apache server. This has the merits of being very
>> straightforward and it seems to be most popular option among other projects.
>>
>> I've proposed on IRC that we may also release every module that forms Allura
>> codebase as a separate tarball. The rationale behind this is that in process of
>> making a release on PyPI, each module will have to be packaged separately
>> anyways. PyPI/pip/setuptools also can work with tarballs and by keeping a single
>> set of distributed archives we can avoid possible confusion on that part. Same
>> tarballs would be uploaded to PyPI and Apache servers.
>>
>> It would be an unusal way to do things, but doesn't seem to conflict the
>> guidelines: http://incubator.apache.org/guides/releasemanagement.html
>>
>> Release process can of course be modified later on, and the way we make releases
>> is important enough to be discussed by whole community here. Anyone's input is
>> welcome, so are any new proposals on the matter.
>>
> 
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Hi!

El mié, 08-05-2013 a las 09:49 +0100, Rui Ferreira escribió:
> I'm travelling so it might take a day or two to get started on this.
> Where should i pull the latest version of the Bitergia module from?

There is a branch with the code:

http://sourceforge.net/p/allura/tickets/5518/

Cheers

> 
> On Wed, May 08, 2013 at 10:17:36AM +0200, Alvaro del Castillo wrote:
> > Hi!
> > 
> > El mié, 08-05-2013 a las 09:11 +0100, Rui Ferreira escribió:
> > > Hi
> > > 
> > > On Wed, May 08, 2013 at 08:36:41AM +0200, Alvaro del Castillo wrote:
> > > > Dear all,
> > > > 
> > > > El mié, 24-04-2013 a las 02:23 +0100, Rui Ferreira escribió:
> > > > > On Tue, Apr 23, 2013 at 06:13:47PM +0200, Roberto Galoppini wrote:
> > > > > > On Tue, Apr 23, 2013 at 6:04 PM, Alvaro del Castillo <acs@bitergia.com>wrote:
> > > > > > 
> > > > > > > El mar, 16-04-2013 a las 17:09 +0200, Roberto Galoppini
escribió:
> > > > > > > > On Tue, Apr 16, 2013 at 12:41 PM, Alvaro del Castillo
<acs@bitergia.com>
> > > > > > > wrote:
> > > > > > > > > Dear all,
> > > > > > > > >
> > > > > > > > > El lun, 15-04-2013 a las 12:21 -0400, Rich Bowen
escribió:
> > > > > > > > >>
> > > > > > > > >> On Jan 8, 2013, at 10:53 PM, Alvaro del Castillo
wrote:
> > > > > > > > >>
> > > > > > > > >> > Thanks Rich. This is just a proposal
and I hope it will be obsoleted
> > > > > > > > >> > in
> > > > > > > > >> > the future with new developments. But
I will have this in mind next
> > > > > > > > >> > time.
> > > > > > > > >> >
> > > > > > > > >> > In any case, the screenshots are now
also in a blog post about the
> > > > > > > > >> > integration:
> > > > > > > > >> >
> > > > > > > http://blog.bitergia.com/2013/01/02/project-analytics-integrated-into-allura/
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> Alvaro, we haven't heard from you in a few
months and I was wondering
> > > > > > > > >> what the status is of your project.
> > > > > > > > >
> > > > > > > > > Yes, you are right. 4 months. I am sorry about
that.
> > > > > > > > >
> > > > > > > > > We have been working so hard in developing the
product and using it to
> > > > > > > > > create reports and dashboards that I have not
found time to reintegrate
> > > > > > > > > all in Allura an continue the development.
> > > > > > > >
> > > > > > > > Alvaro, I'm actively working with the University of
Milan to engage
> > > > > > > > with more students, would be easier for you to reintegrate
new stuff
> > > > > > > > as well as refining the existent?
> > > > > > >
> > > > > > > I am drawing a plan to have the full thing working so we
all understand
> > > > > > > the process, the results and can discuss with a real prototype
(more
> > > > > > > real than the last one) working.
> > > > > > >
> > > > > > > Ideally I will need and Allura node with "real" projects
in which I can
> > > > > > > install the Metrics tools (cvsanaly, bicho and mlstats)
and build the
> > > > > > > complete workflow for having statistics in those projects.
> > > > > > >
> > > > > > > I can setup an Allura node but I have no "real" projects
info to play
> > > > > > > with and build a real prototype. Is it possible to have
an Allura node
> > > > > > > with real projects to play with? If it is not I will try
to recreate a
> > > > > > > forge with some testing data.
> > > > > > >
> > > > > > 
> > > > > 
> > > > > Hi Roberto, thanks for the heads up.
> > > > > 
> > > > > We definitely look with great interest to adding this kind of features
> > > > > to the PROSE deployment, let me know if there is any way we can help
move 
> > > > > this forward.
> > > > 
> > > > Rui, we are working in automating the full process for generating
> > > > reports for Allura projects in a forge. How many projects do you have
in
> > > > PROSE? What king of source code repository are you using? Are you also
> > > > using mailing lists?
> > > > 
> > > 
> > > * Our public release date is more or less now, so we should be able to bring
> > >   some people in,for the upcoming weeks - right now there around ~20
> > >   projects in the website, but most of them are just people testing
> > >   around (or it is our own dev projects).
> > > * Git and SVN for sure
> > > * No mailling lists - Other than the regular Allura mail notifications
> > 
> > Great! If there is enough activity during a period of time in the
> > projects, it could be a good testbed.
> > 
> > > 
> > > > What kind of Linux distro are you using for Allura install? 
> > > > 
> > > 
> > > * Ubuntu LTS 12.04
> > 
> > Nice. In this environment our statistics framework is installed with no
> > probs at all. Rui, I think the next step is to talk with your sys admin
> > guys in order to install all and start testing. is it ok for you? During
> > this work, we can create a complete HOWTO for install the
> > AlluraBitergiaMetrics modules and put it in production for a forge based
> > in Allura.
> > 
> > Kind regards
> > 
> > > 
> > > > 
> > > > > 
> > > > > > My best guess is that the EU-funded project PROSE could be open
to run such
> > > > > > a test on its brand new Allura installation. I've added Rui
who is actually
> > > > > > the person taking care of that infrastructure. Since he's not
subscribed to
> > > > > > this list please keep him copied for further communications.
> > > > > 
> > > > > I do subscribe allura-dev, so no problem there.
> > > > 
> > > > Great! I will continue in this thread.
> > > > 
> > > > > 
> > > > > > 
> > > > > > The reason why I mentioned PROSE infra in this context is that
PROSE aims
> > > > > > to run the latest version of Allura, so coordinating on those
tests could
> > > > > > be a win-win.
> > > > > 
> > > > > We are not fully bleeding edge. Our instance runs on a code base
> > > > > from February. But we are looking into moving to a later version
> > > > > as soon as we get the chance.
> > > > 
> > > > I think we don't need bleeding edge for our metrics plugin for Allura.
> > > > 
> > > > Cheers
> > > > 
> > > > > 
> > > > > BR, Rui
> > > > > 
> > > > > > 
> > > > > > Roberto
> > > > > > 
> > > > > > 
> > > > > > >
> > > > > > > Cheers!
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Roberto
> > > > > > > >
> > > > > > > > >>  Are there any blockers on the Allura side
that are preventing you
> > > > > > > > >> from moving forward with integrating your
changes into the Allura
> > > > > > > > >> code?
> > > > > > > > >
> > > > > > > > > Time to review the current status.
> > > > > > > > >
> > > > > > > > > 1. I have a branch in which I have developed
the Integration of
> > > > > > > > > VizgrimoireJS/VizJS 0.2. I need to update all
to the current Allura
> > > > > > > code
> > > > > > > > > and test that all is working.
> > > > > > > > >
> > > > > > > > > 2. The hard step is how to integrate MetricsGrimoire
(MG, Python toola)
> > > > > > > > > (tools which generates the data needed for VizJS
to viz). MG should be
> > > > > > > > > installed in Allura node (the easy configuration)
and should be started
> > > > > > > > > periodically to gather the data from new projects
or update the old
> > > > > > > > > ones.
> > > > > > > > >
> > > > > > > > > How to program the execution of MG for Allura
projects? This is what we
> > > > > > > > > need to define. It could be directly from "crond"
but maybe, we ca have
> > > > > > > > > a tighter integration so Allura control the execution.
I have research
> > > > > > > a
> > > > > > > > > bit Allura tasks, but I am not sure it this is
the way to go.
> > > > > > > > >
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> I'm pretty sure that I speak for many of
the Allura user community
> > > > > > > > >> when I say that we would *love * to see more,
and better, metrics
> > > > > > > > >> around everything that hosted projects do
on the Allura platform.
> > > > > > > > >
> > > > > > > > > Rich, we have continued the development of VizJS
and now is more
> > > > > > > > > complete. Let's try to finalize how to integrate
everything and
> > > > > > > continue
> > > > > > > > > to move on to build better dashboards and have
richer metrics with more
> > > > > > > > > valuable info!
> > > > > > > > >
> > > > > > > > > My plan is to finish 1 and propose something
for 2, but any clues about
> > > > > > > > > the best integration strategy will be really
appreciated.
> > > > > > > > >
> > > > > > > > > Cheers
> > > > > > > > >
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Rich Bowen
> > > > > > > > >> rbowen@rcbowen.com
> > > > > > > > >> Shosholoza
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > |\_____/| Alvaro del Castillo
> > > > > > > > >  [o] [o]  acs@bitergia.com - CTO, Software Engineer
> > > > > > > > >  |  V  |  http://www.bitergia.com
> > > > > > > > >   |   |
> > > > > > > > > -ooo-ooo-
> > > > > > >
> > > > > > 
> > > > > > -- 
> > > > > > ====
> > > > > > 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.
> > > > > > 
> > > > 
> > > > 
> > > > -- 
> > > > |\_____/| Alvaro del Castillo
> > > >  [o] [o]  acs@bitergia.com - CTO, Software Engineer
> > > >  |  V  |  http://www.bitergia.com
> > > >   |   |
> > > > -ooo-ooo-
> > > > 
> > 
> > 
> > -- 
> > |\_____/| Alvaro del Castillo
> >  [o] [o]  acs@bitergia.com - CTO, Software Engineer
> >  |  V  |  http://www.bitergia.com
> >   |   |
> > -ooo-ooo-
> > 


-- 
|\_____/| Alvaro del Castillo
 [o] [o]  acs@bitergia.com - CTO, Software Engineer
 |  V  |  http://www.bitergia.com
  |   |
-ooo-ooo-

I'm travelling so it might take a day or two to get started on this.
Where should i pull the latest version of the Bitergia module from?

On Wed, May 08, 2013 at 10:17:36AM +0200, Alvaro del Castillo wrote:
> Hi!
> 
> El mié, 08-05-2013 a las 09:11 +0100, Rui Ferreira escribió:
> > Hi
> > 
> > On Wed, May 08, 2013 at 08:36:41AM +0200, Alvaro del Castillo wrote:
> > > Dear all,
> > > 
> > > El mié, 24-04-2013 a las 02:23 +0100, Rui Ferreira escribió:
> > > > On Tue, Apr 23, 2013 at 06:13:47PM +0200, Roberto Galoppini wrote:
> > > > > On Tue, Apr 23, 2013 at 6:04 PM, Alvaro del Castillo <acs@bitergia.com>wrote:
> > > > > 
> > > > > > El mar, 16-04-2013 a las 17:09 +0200, Roberto Galoppini escribió:
> > > > > > > On Tue, Apr 16, 2013 at 12:41 PM, Alvaro del Castillo <acs@bitergia.com>
> > > > > > wrote:
> > > > > > > > Dear all,
> > > > > > > >
> > > > > > > > El lun, 15-04-2013 a las 12:21 -0400, Rich Bowen escribió:
> > > > > > > >>
> > > > > > > >> On Jan 8, 2013, at 10:53 PM, Alvaro del Castillo
wrote:
> > > > > > > >>
> > > > > > > >> > Thanks Rich. This is just a proposal and
I hope it will be obsoleted
> > > > > > > >> > in
> > > > > > > >> > the future with new developments. But I will
have this in mind next
> > > > > > > >> > time.
> > > > > > > >> >
> > > > > > > >> > In any case, the screenshots are now also
in a blog post about the
> > > > > > > >> > integration:
> > > > > > > >> >
> > > > > > http://blog.bitergia.com/2013/01/02/project-analytics-integrated-into-allura/
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Alvaro, we haven't heard from you in a few months
and I was wondering
> > > > > > > >> what the status is of your project.
> > > > > > > >
> > > > > > > > Yes, you are right. 4 months. I am sorry about that.
> > > > > > > >
> > > > > > > > We have been working so hard in developing the product
and using it to
> > > > > > > > create reports and dashboards that I have not found
time to reintegrate
> > > > > > > > all in Allura an continue the development.
> > > > > > >
> > > > > > > Alvaro, I'm actively working with the University of Milan
to engage
> > > > > > > with more students, would be easier for you to reintegrate
new stuff
> > > > > > > as well as refining the existent?
> > > > > >
> > > > > > I am drawing a plan to have the full thing working so we all
understand
> > > > > > the process, the results and can discuss with a real prototype
(more
> > > > > > real than the last one) working.
> > > > > >
> > > > > > Ideally I will need and Allura node with "real" projects in
which I can
> > > > > > install the Metrics tools (cvsanaly, bicho and mlstats) and
build the
> > > > > > complete workflow for having statistics in those projects.
> > > > > >
> > > > > > I can setup an Allura node but I have no "real" projects info
to play
> > > > > > with and build a real prototype. Is it possible to have an Allura
node
> > > > > > with real projects to play with? If it is not I will try to
recreate a
> > > > > > forge with some testing data.
> > > > > >
> > > > > 
> > > > 
> > > > Hi Roberto, thanks for the heads up.
> > > > 
> > > > We definitely look with great interest to adding this kind of features
> > > > to the PROSE deployment, let me know if there is any way we can help move

> > > > this forward.
> > > 
> > > Rui, we are working in automating the full process for generating
> > > reports for Allura projects in a forge. How many projects do you have in
> > > PROSE? What king of source code repository are you using? Are you also
> > > using mailing lists?
> > > 
> > 
> > * Our public release date is more or less now, so we should be able to bring
> >   some people in,for the upcoming weeks - right now there around ~20
> >   projects in the website, but most of them are just people testing
> >   around (or it is our own dev projects).
> > * Git and SVN for sure
> > * No mailling lists - Other than the regular Allura mail notifications
> 
> Great! If there is enough activity during a period of time in the
> projects, it could be a good testbed.
> 
> > 
> > > What kind of Linux distro are you using for Allura install? 
> > > 
> > 
> > * Ubuntu LTS 12.04
> 
> Nice. In this environment our statistics framework is installed with no
> probs at all. Rui, I think the next step is to talk with your sys admin
> guys in order to install all and start testing. is it ok for you? During
> this work, we can create a complete HOWTO for install the
> AlluraBitergiaMetrics modules and put it in production for a forge based
> in Allura.
> 
> Kind regards
> 
> > 
> > > 
> > > > 
> > > > > My best guess is that the EU-funded project PROSE could be open to
run such
> > > > > a test on its brand new Allura installation. I've added Rui who is
actually
> > > > > the person taking care of that infrastructure. Since he's not subscribed
to
> > > > > this list please keep him copied for further communications.
> > > > 
> > > > I do subscribe allura-dev, so no problem there.
> > > 
> > > Great! I will continue in this thread.
> > > 
> > > > 
> > > > > 
> > > > > The reason why I mentioned PROSE infra in this context is that PROSE
aims
> > > > > to run the latest version of Allura, so coordinating on those tests
could
> > > > > be a win-win.
> > > > 
> > > > We are not fully bleeding edge. Our instance runs on a code base
> > > > from February. But we are looking into moving to a later version
> > > > as soon as we get the chance.
> > > 
> > > I think we don't need bleeding edge for our metrics plugin for Allura.
> > > 
> > > Cheers
> > > 
> > > > 
> > > > BR, Rui
> > > > 
> > > > > 
> > > > > Roberto
> > > > > 
> > > > > 
> > > > > >
> > > > > > Cheers!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Roberto
> > > > > > >
> > > > > > > >>  Are there any blockers on the Allura side that
are preventing you
> > > > > > > >> from moving forward with integrating your changes
into the Allura
> > > > > > > >> code?
> > > > > > > >
> > > > > > > > Time to review the current status.
> > > > > > > >
> > > > > > > > 1. I have a branch in which I have developed the Integration
of
> > > > > > > > VizgrimoireJS/VizJS 0.2. I need to update all to the
current Allura
> > > > > > code
> > > > > > > > and test that all is working.
> > > > > > > >
> > > > > > > > 2. The hard step is how to integrate MetricsGrimoire
(MG, Python toola)
> > > > > > > > (tools which generates the data needed for VizJS to
viz). MG should be
> > > > > > > > installed in Allura node (the easy configuration)
and should be started
> > > > > > > > periodically to gather the data from new projects
or update the old
> > > > > > > > ones.
> > > > > > > >
> > > > > > > > How to program the execution of MG for Allura projects?
This is what we
> > > > > > > > need to define. It could be directly from "crond"
but maybe, we ca have
> > > > > > > > a tighter integration so Allura control the execution.
I have research
> > > > > > a
> > > > > > > > bit Allura tasks, but I am not sure it this is the
way to go.
> > > > > > > >
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> I'm pretty sure that I speak for many of the Allura
user community
> > > > > > > >> when I say that we would *love * to see more,
and better, metrics
> > > > > > > >> around everything that hosted projects do on the
Allura platform.
> > > > > > > >
> > > > > > > > Rich, we have continued the development of VizJS and
now is more
> > > > > > > > complete. Let's try to finalize how to integrate everything
and
> > > > > > continue
> > > > > > > > to move on to build better dashboards and have richer
metrics with more
> > > > > > > > valuable info!
> > > > > > > >
> > > > > > > > My plan is to finish 1 and propose something for 2,
but any clues about
> > > > > > > > the best integration strategy will be really appreciated.
> > > > > > > >
> > > > > > > > Cheers
> > > > > > > >
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Rich Bowen
> > > > > > > >> rbowen@rcbowen.com
> > > > > > > >> Shosholoza
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > |\_____/| Alvaro del Castillo
> > > > > > > >  [o] [o]  acs@bitergia.com - CTO, Software Engineer
> > > > > > > >  |  V  |  http://www.bitergia.com
> > > > > > > >   |   |
> > > > > > > > -ooo-ooo-
> > > > > >
> > > > > 
> > > > > -- 
> > > > > ====
> > > > > 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.
> > > > > 
> > > 
> > > 
> > > -- 
> > > |\_____/| Alvaro del Castillo
> > >  [o] [o]  acs@bitergia.com - CTO, Software Engineer
> > >  |  V  |  http://www.bitergia.com
> > >   |   |
> > > -ooo-ooo-
> > > 
> 
> 
> -- 
> |\_____/| Alvaro del Castillo
>  [o] [o]  acs@bitergia.com - CTO, Software Engineer
>  |  V  |  http://www.bitergia.com
>   |   |
> -ooo-ooo-
>