Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gstein@gmail.com designates
 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <b0322133-ac6a-41bc-bdc8-95458cedee29@email.android.com>
References: <50102A61.6090908@wandisco.com>
	<CABD8fLXnGyrrBv4vghHkvcE+-2G668kDWn6YnDg0Z0esgSPd0w@mail.gmail.com>
	<b0322133-ac6a-41bc-bdc8-95458cedee29@email.android.com>
Date: Thu, 2 Aug 2012 21:14:37 -0400
Message-ID: 
 <CABD8fLX-tpwhngrv3_iKaHMp33psbB284nbELe-G6AyfK_5xPA@mail.gmail.com>
Subject: Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating) (RC1)
From: Greg Stein <gstein@gmail.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

I would suggest running with the current tarball. You've got something
for the IPMC to comment upon. If it doesn't pass muster, then fine:
you'll just end up rolling up a new tarball anyways. May as well be
optimistic, and get some feedback while you're at it.

When forwarding to the IPMC, you may want to note that I've found some
licensing/notice issues which are planned to be fixed in the next
release. That will at least let them know we've seen them and intend
to fix them. (and it may help to have my name in there as
reviewed/approved) Each of the people who approved it (in a binding
fashion) should be listed in that email.

Cheers,
-g

On Thu, Aug 2, 2012 at 6:55 PM, Gary Martin <gary.martin@wandisco.com> wrote:
> Thanks for that Greg. I will raise tickets and fix as much of that as I can in the morning.
>
> That leaves the question of whether I should create the new release with these changes or carry on with the current tarball. Any other opinions?
>
> Cheers,
>     Gary
>
>
>
> Greg Stein <gstein@gmail.com> wrote:
>
>>On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <gary.martin@wandisco.com>
>>wrote:
>>>...
>>> Please vote:
>>> [ ] +1 Release this package as Apache Bloodhound 0.1.0
>>> [ ] +0 Don't care
>>> [ ] -1 Do not release this package (please explain)
>>
>>+1 to release.
>>
>>Changes that I'd suggest for the next release:
>>
>>* append dependencies' licenses to LICENSE (in addition to their
>>reference in NOTICE)
>>* remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level
>>dir is proper. (and maybe generally simplify; eg. why CHANGES in
>>bloodhound_dashboard?)
>>* found another NOTICE in doc/html-templates/ (?!)
>>* is doc/wireframes supposed to be shipped in the release?
>>* found another LICENSE/NOTICE pair in installer/
>>* files like bloodhound_dashboard/setup.cfg (and other .ini format
>>files like ticket_data.ini) could use a license header (use of RAT
>>will find more of these)
>>  - same with bloodhound_dashboard/macros.py
>>  - run RAT before 0.2 release
>>* in bloodhound_dashboard/bhdashboard/templates/bh_model_view.html,
>>then comment holding the license header comes before the DOCTYPE
>>element. not sure that is (formally) allowed. probably should have the
>>DOCTYPE, then the comment, then the <div>
>>* might be nice to have a top-level README that points to
>>installer/README.rst
>>* would also be nice to indicate what release/revision of Trac is
>>incorporated into this release, along with a notice that local patches
>>have been applied. (on that note: has anybody worked to push the local
>>changes upstream?)
>>
>>
>>That's all for now. While I think this it is fine to release in this
>>shape, I might also suggest incorporating the above changes and
>>produce a 0.1 tarball (no RC1 designator) and shoot that out for
>>another BH release vote followed by IPMC vote. (the IPMC vote will be
>>easier if RAT is run first, but I can beat down any hubbub even on
>>this RC1 if you go that route).
>>
>>On version numbers in general, they are cheap. There is no reason to
>>have 0.1.0-RC1. Just call it 0.1 or 0.1.0. If you decide NOT to
>>release it, then make the next one 0.2 or 0.1.1. Never re-use a
>>number! ... but there isn't a reason to be so conservative as to make
>>a 0.1.0-RC1 tarball. In the long run, you probably want a standard
>>triple, so going with 0.1.0 makes sense. If people nuke that proposed
>>tarball, then spin up a new one called 0.1.1. As I've mentioned
>>before, once 0.1.x is out there, you probably wouldn't patch it at
>>this point of BH's lifecycle, and just go straight to 0.2.0 instead.
>>(tho I guess if it is a total brown-bag release, you could also do a
>>teeny patch and push out 0.1.x+1).
>>
>>Anyways. Food for thought. Again, I'm +1 on this tarball for release.
>>
>>Cheers,
>>-g
>