On 01/13/2012 06:03 AM, M. David Peterson wrote:
On Thu, Jan 12, 2012 at 2:10 AM, Alvaro Lopez Ortega
<[email protected] <mailto:[email protected]>> wrote:
However, we do miss all kinds of Integration and User Acceptance
tests. Problems like the "A1" trailing bug in the first alpha of
the 1.3.0 series should have been detected by those tests. They
could cover: compilation, cross-compilation, system integration
(rrdtool support, log files, etc) and even the proper function of
cherokee-admin.
For catching simple issues before committing (i.e. doesn't require
configuring, building, installing, launching, and running the test
suite) a pre-commit-hook can help avoid the more common issues most
often related to Sleepy Hacker Build Breaking Syndrome. More
extensive tests will need to be handled by developing a workflow that
can be scripted and added to our local dev machines as an alias
function. Should we create a wiki page on github/cherokee/webserver
to begin documenting the process as we work through that process here
on the dev list?
Sure. That'd be a great first step. I've just added to the team, so I
guess you should be able to add new wiki pages now.
It is neither a trivial task, nor something that can be
implemented over night. However, if done properly, it could have a
HUGE positive impact on the project. I'm well aware of this, so if
you finally take over the QA effort, I'll do my best to be
involved with it and help as much as possible.
How do you feel about creating a separate qa git repository under the
cherokee organization that can then be included as a module in place
of the current ~/qa directory? This would also allow a clean
separation of the wiki, issues, and pull requests sections as well as
a separate project page at http://cherokee.github.com/qa. What do you
think?
It'd be fine, but we would have to take care of clarifying the scope. I
mean, the current QA does only cover to the functionality of the server,
and pieces like CTK and cherokee-admin are currently not being tested.
A "qa" module in the Cherokee org. could be understood as a wider effort
than what it currently is. We could either integrate the rest of the QA
efforts in there, or we rename it to something more accurate.
I'd vote for the first one. We'd have to work out a couple of
assumptions of the current QA bench (as expecting cherokee-worker in
../cherokee/), but I believe would be the most flexible option in the
middle term. What do you think?
All the best,
Alvaro
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
