Mailing List Archive

Great news!! but is the source tarball broken? i can not extract it.

Best regards,
Sharl.Jimh.Tsin (From China **Obviously Taiwan INCLUDED**)

Using Gmail? Please read this important notice:
http://www.fsf.org/campaigns/jstrap/gmail?10073.



2012/1/8 Alvaro Lopez Ortega <alvaro@alobbs.com>:
> Hi folks, happy new year!
>
> I just wanted to drop a line to let you know that I've uploaded the first
> pre-release of Cherokee 1.3.0.
>
> Many important changes were made in the server core in order to make the
> Cherokee more flexible. Be aware that some of those changes were
> quite intrusive, and therefore they might have introduce some regressions.
>
> Cherokee 1.3.0 Alpha1 seems to work smoothly, although you are advised not
> to use it on production environments. I like to request your feedback about
> it though, specially if it is related to SSL/TLS, stability and performance.
>
> http://www.cherokee-project.com/download/pre-releases/cherokee-1.3.0A1.tar.gz
>
> Enjoy it!!
>
> --
> Greetings, alo.
> http://www.alobbs.com/
>
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee
>
_______________________________________________
Cherokee mailing list
Cherokee@lists.octality.com
http://lists.octality.com/listinfo/cherokee

Hey Alvaro :)

On Sat, Jan 7, 2012 at 2:56 PM, Alvaro Lopez Ortega <alvaro@alobbs.com>wrote:

> Hi folks, happy new year!
>

Happy New Year!


> I just wanted to drop a line to let you know that I've uploaded the first
> pre-release of Cherokee 1.3.0.
>

Great! I've been watching the 'new-events' branch with much anticipation.
Glad to see things have reached the first alpha release stage!


> Many important changes were made in the server core in order to make the
> Cherokee more flexible. Be aware that some of those changes were
> quite intrusive, and therefore they might have introduce some regressions.
>
> Cherokee 1.3.0 Alpha1 seems to work smoothly, although you are advised not
> to use it on production environments. I like to request your feedback about
> it though, specially if it is related to SSL/TLS, stability and performance.
>

The only issue I've run into so far has to do with cherokee-admin being
inaccessible (503 timeout error) due to an attempt to parse the revision
(0A1) of the version as an integer. A quick hack has been pushed to my fork
and a pull request sent > https://github.com/cherokee/webserver/pull/17 <


> Enjoy it!!
>

Thanks Alvaro! Enjoyment in progress... :-) Will continue to play around
with the bits and see what else I can find.

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david@3rdandUrban.com
Voice: (801) 742-1064
http://amp.fm | http://mdavidpeterson.com

Hello David,

Thanks for the feedback. I've just uploaded a fixed version of the tarball:

http://www.cherokee-project.com/download/pre-releases/cherokee-1.3.0A2.tar.gz

It's basically the same code, packed in a new tarball with a regular
version string.

Cheers!


On Tue, Jan 10, 2012 at 7:36 AM, M. David Peterson
<m.david@3rdandurban.com>wrote:

> Hey Alvaro :)
>
> On Sat, Jan 7, 2012 at 2:56 PM, Alvaro Lopez Ortega <alvaro@alobbs.com>wrote:
>
>> Hi folks, happy new year!
>>
>
> Happy New Year!
>
>
>> I just wanted to drop a line to let you know that I've uploaded the first
>> pre-release of Cherokee 1.3.0.
>>
>
> Great! I've been watching the 'new-events' branch with much anticipation.
> Glad to see things have reached the first alpha release stage!
>
>
>> Many important changes were made in the server core in order to make the
>> Cherokee more flexible. Be aware that some of those changes were
>> quite intrusive, and therefore they might have introduce some regressions.
>>
>> Cherokee 1.3.0 Alpha1 seems to work smoothly, although you are advised
>> not to use it on production environments. I like to request your feedback
>> about it though, specially if it is related to SSL/TLS, stability and
>> performance.
>>
>
> The only issue I've run into so far has to do with cherokee-admin being
> inaccessible (503 timeout error) due to an attempt to parse the revision
> (0A1) of the version as an integer. A quick hack has been pushed to my fork
> and a pull request sent > https://github.com/cherokee/webserver/pull/17 <
>
>
>> Enjoy it!!
>>
>
> Thanks Alvaro! Enjoyment in progress... :-) Will continue to play around
> with the bits and see what else I can find.
>
> --
> /M:D
>
> M. David Peterson
> Co-Founder & Chief Architect, 3rd&Urban, LLC
> Email: m.david@3rdandUrban.com
> Voice: (801) 742-1064
> http://amp.fm | http://mdavidpeterson.com
>



--
Greetings, alo.
http://www.alobbs.com/

Good!

Is there a Changelog in the package or in the webpage ?

Thx!

On 10/01/12 15:14, Alvaro Lopez Ortega wrote:
> Hello David,
>
> Thanks for the feedback. I've just uploaded a fixed version of the
> tarball:
>
> http://www.cherokee-project.com/download/pre-releases/cherokee-1.3.0A2.tar.gz
>
> It's basically the same code, packed in a new tarball with a regular
> version string.
>
> Cheers!
>
>
> On Tue, Jan 10, 2012 at 7:36 AM, M. David Peterson
> <m.david@3rdandurban.com <mailto:m.david@3rdandurban.com>> wrote:
>
> Hey Alvaro :)
>
> On Sat, Jan 7, 2012 at 2:56 PM, Alvaro Lopez Ortega
> <alvaro@alobbs.com <mailto:alvaro@alobbs.com>> wrote:
>
> Hi folks, happy new year!
>
>
> Happy New Year!
>
> I just wanted to drop a line to let you know that I've
> uploaded the first pre-release of Cherokee 1.3.0.
>
>
> Great! I've been watching the 'new-events' branch with much
> anticipation. Glad to see things have reached the first alpha
> release stage!
>
> Many important changes were made in the server core in order
> to make the Cherokee more flexible. Be aware that some of
> those changes were quite intrusive, and therefore they might
> have introduce some regressions.
>
> Cherokee 1.3.0 Alpha1 seems to work smoothly, although you are
> advised not to use it on production environments. I like to
> request your feedback about it though, specially if it is
> related to SSL/TLS, stability and performance.
>
>
> The only issue I've run into so far has to do with cherokee-admin
> being inaccessible (503 timeout error) due to an attempt to parse
> the revision (0A1) of the version as an integer. A quick hack has
> been pushed to my fork and a pull request sent >
> https://github.com/cherokee/webserver/pull/17 <
>
> Enjoy it!!
>
>
> Thanks Alvaro! Enjoyment in progress... :-) Will continue to play
> around with the bits and see what else I can find.
>
> --
> /M:D
>
> M. David Peterson
> Co-Founder & Chief Architect, 3rd&Urban, LLC
> Email: m.david@3rdandUrban.com
> Voice: (801) 742-1064 <tel:%28801%29%20742-1064>
> http://amp.fm | http://mdavidpeterson.com
>
>
>
>
> --
> Greetings, alo.
> http://www.alobbs.com/
>
>
> _______________________________________________
> Cherokee mailing list
> Cherokee@lists.octality.com
> http://lists.octality.com/listinfo/cherokee

On Tue, Jan 10, 2012 at 1:14 PM, Alvaro Lopez Ortega <alvaro@alobbs.com>wrote:

>
> It's basically the same code, packed in a new tarball with a regular
> version string.
>

Perfect! Builds and installs as expected, and all scripts and binaries
(cherokee > ~-worker, cherokee-admin (with desired options), and
cherokee-admin-launcher (without any options specified)) launch without
issue and thus far run exactly as expected on both OS X Lion and Ubuntu
Oneiric x64.

Question: Given the nature of what appears to be a massive architectural
redesign of the underlying cherokee core, should we spend some time pulling
together an ad-hoc build/test/deploy test suite that can be easily
cloned/used/contributed to by the community to ensure we are able to
find/report/squash any regressions that may be introduced along the way on
as many hardware and software platforms as the community-at-large
represents?

That's actually a project I'd be happy to head-up and run with in the
background while you continue to kick-a$$ coding up all the backend
goodness that will undoubtedly result of your redesign work. Let me know
if you like the idea and I'll start pulling things together and pushing it
forward if you do. :)

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david@3rdandUrban.com
Voice: (801) 742-1064
http://amp.fm | http://mdavidpeterson.com

On 01/11/2012 02:33 AM, M. David Peterson wrote:
> On Tue, Jan 10, 2012 at 1:14 PM, Alvaro Lopez Ortega
> <alvaro@alobbs.com <mailto:alvaro@alobbs.com>> wrote:
>
>
> It's basically the same code, packed in a new tarball with a
> regular version string.
>
>
> Perfect! Builds and installs as expected, and all scripts and binaries
> (cherokee > ~-worker, cherokee-admin (with desired options), and
> cherokee-admin-launcher (without any options specified)) launch
> without issue and thus far run exactly as expected on both OS X Lion
> and Ubuntu Oneiric x64.
>
> Question: Given the nature of what appears to be a massive
> architectural redesign of the underlying cherokee core, should we
> spend some time pulling together an ad-hoc build/test/deploy test
> suite that can be easily cloned/used/contributed to by the community
> to ensure we are able to find/report/squash any regressions that may
> be introduced along the way on as many hardware and software platforms
> as the community-at-large represents?

That would be a great thing to do. Actually, it is the sort of thing
that should have been scheduled as a very high-priority task if we had
enough resources.

I'm going to spend the next few months working on architectural
improvements. The target is to all fix the issues that have popped up
during the last couple of years, and to get the server architecture
ready for implementing the new technologies that seem to be gaining
acceptance among the Web-tech community.

All in all, I'm afraid I won't have enough bandwidth to work on QA while
I'm doing all the architecture changes, so it'd be awesome if you could
take over the QA effort.

Our current QA bench is composed by almost 300 functional tests. It has
proven to be a really useful tool worth investing work on. Of course
there is room for improvement there, but it is a fairly acceptable
functional test bench.

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.

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.

> That's actually a project I'd be happy to head-up and run with in the
> background while you continue to kick-a$$ coding up all the backend
> goodness that will undoubtedly result of your redesign work. Let me
> know if you like the idea and I'll start pulling things together and
> pushing it forward if you do. :)

It'd be absolutely fantastic :-)


All the best,
Alvaro

On 01/10/2012 09:42 PM, Alvaro [Andor] wrote:
> Good!
>
> Is there a Changelog in the package or in the webpage ?

We are no longer including the ChangeLog file in the tarballs. Instead,
you can check the git log to read the description of the commits.

Since this is not an actual release, I did not tagged the repo (Maybe I
should have). However, you will be able to get the full change list with
"git shortlog v1.2.102..v1.3.0" as soon as the release is ready.


All the best,
Alvaro

On Thu, Jan 12, 2012 at 2:24 AM, Alvaro Lopez Ortega <alvaro@octality.com>wrote:

> Since this is not an actual release, I did not tagged the repo (Maybe I
> should have).


I would definitely tag anything that's been pushed out into the public
ether for evaluation. If for no other reason (and there are several*) it
allows for ease of using git to push out experimental changes, applied
patches, etc. in which we can then switch back and forth between
branches/tags without need to download and extract a new tarball.

* Since `make` will keep track of changed files and only rebuild the .o
file related to those files it avoids having to reconfigure/rebuild
everything even if only minor changes have been made. Obviously not a good
practice when switching between major releases where make may not pick up
on all changes made to the overall build process, for smaller changes this
is much preferable IMO.
* Given github will generate a tarball for each new tag, for those not
using git it makes it easier to manage the downloads related to each tagged
entry.**

** The one caveat to this is that the source of external modules will not
be included in the tarball so an additional step would need to be added to
the makefile to check whether or not the source for a given submodule
exists and if doesn't download and extracted the related tagged tarball
from the related project before preceding with the build.

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david@3rdandUrban.com
Voice: (801) 742-1064
http://amp.fm | http://mdavidpeterson.com

On Thu, Jan 12, 2012 at 2:10 AM, Alvaro Lopez Ortega <alvaro@alobbs.com>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?

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?

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david@3rdandUrban.com
Voice: (801) 742-1064
http://amp.fm | http://mdavidpeterson.com

On Thu, Jan 12, 2012 at 10:03 PM, M. David Peterson <m.david@3rdandurban.com
> wrote:

> 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.


Forgot to make note of the fact that 'yes, I will absolutely take over the
QA effort!' < Excited! :-)

--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david@3rdandUrban.com
Voice: (801) 742-1064
http://amp.fm | http://mdavidpeterson.com

On 01/13/2012 06:03 AM, M. David Peterson wrote:
> On Thu, Jan 12, 2012 at 2:10 AM, Alvaro Lopez Ortega
> <alvaro@alobbs.com <mailto:alvaro@alobbs.com>> 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

On Fri, Jan 13, 2012 at 4:00 AM, Alvaro Lopez Ortega <alvaro@alobbs.com>wrote:

> I'd vote for the first one.

...

> What do you think?


+1: Makes perfect sense. Starting with a blank slate for the new QA process
and then integrating the existing QA modules from the webserver repository
once it makes sense to do so (i.e. letting both the webserver architectural
update and QA project mature properly on their own before and then bridging
them together once it makes sense to do so). I like it! Can you go ahead
and create a the new ~/cherokee/qa.git project when you have a moment?


--
/M:D

M. David Peterson
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: m.david@3rdandUrban.com
Voice: (801) 742-1064
http://amp.fm | http://mdavidpeterson.com