incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: moving towards initial release
Date Wed, 04 Jul 2012 18:00:54 GMT
On 07/02/2012 10:54 PM, Olemis Lang wrote:
> On 7/2/12, Gary Martin <> wrote:
>> Anyway, as a fundamental part of a release is that it consists of the
>> necessary source to build the project, we need to make sure that our
>> installer is fit for the task of installing in that form, or, at least,
>> we give adequate instructions for how the project is built without using
>> the simple installer. Either way, changes to the installer should be
>> expected.
> About this I wanted to suggest you to take a look at Trac's Makefile .
> That approach seems to be connsistent with Trac develeopment workflow
> and afaics might help to build packages for specific platforms and
> environments (e.g. Linux dpkg , rpm ... , Windows msi , exe ...
> database PostgreSQL , SQLite , ... and so on ) . Maybe it'd be nice to
> add new Bloodhound-specific targets in there e.g. bloodhound_configure
> bloodhound_install , ...

Well, we can already create binary and source distributions with 
distutils. It might be nice to have a buildout recipe for installation 
as well for an alternative installation and setup.

The pip install route still seems like a nice way to go but, with these 
comments in mind, I have been experimenting with removing the automation 
of the pip installs. With the requirements files we can continue to 
encourage users to do their own pip installs with, or without, 
virtualenv. In fact this might solve some problems on OS X where I seem 
to remember issues with requiring XCode for virtualenv.

Anyway, there is no particular requirement for binary distributions to 
be made available though we could consider whether this would be good 
for future releases.

>> Any advice would be
>> great. It will probably help for us to have a set of standard tickets
>> that we can use to track our progress that can be replicated for future
>> releases.
> ... and if release process (... or part of it ...) can be automated
> with Jenkins or Hudson or ... that may be a good starting point .

Yes, I am sure that we will be able to streamline the process in some way.


View raw message