On Wed, Jul 25, 2012 at 1:18 PM, Gary Martin <[email protected]> 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
