From bloodhound-dev-return-445-apmail-incubator-bloodhound-dev-archive=incubator.apache.org@incubator.apache.org Wed Jul 4 18:01:27 2012 Return-Path: X-Original-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-bloodhound-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DDA4C91F2 for ; Wed, 4 Jul 2012 18:01:26 +0000 (UTC) Received: (qmail 38960 invoked by uid 500); 4 Jul 2012 18:01:26 -0000 Delivered-To: apmail-incubator-bloodhound-dev-archive@incubator.apache.org Received: (qmail 38900 invoked by uid 500); 4 Jul 2012 18:01:26 -0000 Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: bloodhound-dev@incubator.apache.org Delivered-To: mailing list bloodhound-dev@incubator.apache.org Received: (qmail 38881 invoked by uid 99); 4 Jul 2012 18:01:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 18:01:26 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gary.martin@wandisco.com designates 74.125.83.47 as permitted sender) Received: from [74.125.83.47] (HELO mail-ee0-f47.google.com) (74.125.83.47) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 18:01:18 +0000 Received: by eekd49 with SMTP id d49so2983919eek.6 for ; Wed, 04 Jul 2012 11:00:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=jpdfoWOlH3so5uDRvBnAMEMxrWNAYJwhUzNS/9KA6y0=; b=VnnrwAeRGRbfj8Gd6jBrdnucb8aBwi4lT4QSB/n+iUqRcmJQHV9MtHkX8fZtTphiEo UbOvYviwfK/rPZtvvPqppXuYmGCQLB2Jokpw7+jV3xyP+bGws68yRcigoHyHMbZ/Uwy6 uaEuvhUZu8lba9Lp7910OqQHbYhLQtgmL4IrHgnkA5SvXoFCHs8Tq7PmDnS6zzMtrdut iXE1r8sEwTRH1aJERCy41c215QJKkB3XVTO8YoIVoVDfgM9s5UJcRcpgBCHcX6baAoiq RK4R8JDiB4TO7M35+BZOFgjzb/bYPh/ml37oWQXLAofg65c6ld3OQbFuqijSSXDhSfPW Oclg== Received: by 10.14.186.3 with SMTP id v3mr5389693eem.212.1341424857391; Wed, 04 Jul 2012 11:00:57 -0700 (PDT) Received: from [10.2.5.127] ([77.86.30.139]) by mx.google.com with ESMTPS id s4sm56092652eef.2.2012.07.04.11.00.56 (version=SSLv3 cipher=OTHER); Wed, 04 Jul 2012 11:00:56 -0700 (PDT) Message-ID: <4FF484D6.8070603@wandisco.com> Date: Wed, 04 Jul 2012 19:00:54 +0100 From: Gary Martin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: bloodhound-dev@incubator.apache.org Subject: Re: moving towards initial release References: <4FF164A6.6080908@wandisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmvMoclVYH2QKNseQ1kDliihpPCS8s/phdnj4gHWFLWGSIuoRTqE351xMFM+zctK+EjUgkV 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. Cheers, Gary