Thesis about open source projects
My name is Michael Simonetto, I'm a student in Brussels finishing my thesis about communication in open source projects. I need some interviews to illustrate and complete my work and have thought the mailing list would be a convenient way to find some developers kind enough to help me! I don't know if I may send attachments to this mailing list, so if you are intrested, please reply and I'll send you the questions! We can also meet on IRC or any communication channel you wish to use... Thanks a lot! Michael PS : I'm afraid to say it's awfully urgent... (thesis due 18 august...), so if you don't have time, you don't need to fully answer the questionnaire...
about httpd installer
Hi all, I'm a PMC member of the Apache JAMES project. We received a contribution from an user including an installer for our main product (Apache JAMES Server). The installer is for the Windows platform and is created using a commercial product named SetupBuilder. I pointed the user that we couldn't use it in JAMES product because #1 SetupBuilder was commercial and #2 it required our release manager to run on windows in order to create the instealler. He pointed me that APache HTTPD has a windows installer based on a commercial product too (Installshield). Can you kindly give more details on how you dealt with this? Thank you, Stefano
Re: worker MPM on trunk does not shut down cleanly
On Aug 1, 2008, at 4:44 AM, Mladen Turk wrote: Ruediger Pluem wrote: Ok, this is caused by http://svn.apache.org/viewvc? rev=677505view=rev This is the reslist pre_cleanup patch. I don't know why so far, but as I have a proxy configuration I suspect that it blocks on tearing down the proxy connection pools. Here is the fix for trunk. Index: proxy_util.c === --- proxy_util.c(revision 681621) +++ proxy_util.c(working copy) @@ -1939,10 +1939,11 @@ worker-hmax, worker-ttl, connection_constructor, connection_destructor, worker, worker-cp-pool); - +#if 0 apr_pool_cleanup_register(worker-cp-pool, (void *)worker, conn_pool_cleanup, apr_pool_cleanup_null); +#endif Note that because of using pre_cleanup in reslist we don't need the extra registered cleanup (conn_pool_cleanup), just to make sure the ordering is correct. This was bogus anyhow, because we were destroying the reslist in cleanup (that already has it's own cleanup), so the ordering of cleanup callbacks was essential. I wonder how many other just uses in other modules would be just so affected? So does this mean that trunk is now based on a broken or incompatible version of apr? Do we need to now break off trunk to 2.4 and baseline APR 1.3 to allow trunk to now work with an incompatible APR rev?
Re: worker MPM on trunk does not shut down cleanly
On 08/03/2008 06:28 PM, Jim Jagielski wrote:
On Aug 1, 2008, at 4:44 AM, Mladen Turk wrote:
Ruediger Pluem wrote:
Ok, this is caused by http://svn.apache.org/viewvc?rev=677505view=rev
This is the reslist pre_cleanup patch. I don't know why so far, but as
I have a proxy configuration I suspect that it blocks on tearing down
the proxy connection pools.
Here is the fix for trunk.
Index: proxy_util.c
===
--- proxy_util.c(revision 681621)
+++ proxy_util.c(working copy)
@@ -1939,10 +1939,11 @@
worker-hmax, worker-ttl,
connection_constructor,
connection_destructor,
worker, worker-cp-pool);
-
+#if 0
apr_pool_cleanup_register(worker-cp-pool, (void *)worker,
conn_pool_cleanup,
apr_pool_cleanup_null);
+#endif
Note that because of using pre_cleanup in reslist we don't need
the extra registered cleanup (conn_pool_cleanup),
just to make sure the ordering is correct.
This was bogus anyhow, because we were destroying the reslist in
cleanup (that already has it's own cleanup), so the ordering of
cleanup callbacks was essential.
I wonder how many other just uses in other modules would be just
so affected?
So does this mean that trunk is now based on a broken or
incompatible version of apr? Do we need to now break off
trunk to 2.4 and baseline APR 1.3 to allow trunk to now work
with an incompatible APR rev?
As far as this specific issue is concerned, IMHO no. The following
patch fixes the behaviour on trunk (with apr-util trunk) and does no
harm on 2.2.x:
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (Revision 681204)
+++ modules/proxy/proxy_util.c (Arbeitskopie)
@@ -1380,7 +1380,6 @@
proxy_worker *worker = (proxy_worker *)theworker;
if (worker-cp-res) {
worker-cp-pool = NULL;
-apr_reslist_destroy(worker-cp-res);
}
return APR_SUCCESS;
}
Why?
Trunk (with apr-util trunk):
At the point of time we would execute apr_reslist_destroy the reslist is
already destroyed,
because we are in a cleanup of the same pool where the reslist registered
itself as
precleanup. This causes the lock at shutdown.
2.2.x:
Calling apr_reslist_destroy is not really useful and needed in this case as we
are in a cleanup
that was registered against the same pool that is used by the reslist. As it
was registered
*after* the reslist was created it just runs *before* the reslist cleanup would
run. This
is somewhat pointless here and we could leave the job of destroying the reslist
to the
reslist cleanup.
Nevertheless I think that the precleanup code in apr trunk and the changes to
the reslist
in apr-util trunk are not backportable just because of the example above: Code
may break
if you change an apr / apr-util 1.3 release under the hood. This should not
happen.
Regards
Rüdiger
Re: worker MPM on trunk does not shut down cleanly
Jim Jagielski wrote: So does this mean that trunk is now based on a broken or incompatible version of apr? Do we need to now break off trunk to 2.4 and baseline APR 1.3 to allow trunk to now work with an incompatible APR rev? There's no such thing as an incompatible APR revision. Those would be bugs that need to be reverted, and patches are welcome. This should be considered an incompatible version of APR w.r.t. those features. There will have to be a 2.4 (or 3.0) once we decide to adopt APR 2, because there will be no binary or legacy compatibility thunks. But in the meantime, it's enough to recommend a particular version, e.g. state that APR 1.3.3 is required for httpd 2.2.9 and later. Older modules will still load and should continue to behave as they had. The reslist debate has bogged down [EMAIL PROTECTED] progress towards a 1.3.3 release, but until the debate is resolved and apr 1.2.x behavior is restored, it's pointless to move forwards. So the more eyes the merrier (both Mladen and Bojan are asking for additional review!)
Re: about httpd installer
On Aug 3, 2008, at 9:19 AM, Stefano Bagnara wrote: I'm a PMC member of the Apache JAMES project. We received a contribution from an user including an installer for our main product (Apache JAMES Server). The installer is for the Windows platform and is created using a commercial product named SetupBuilder. I pointed the user that we couldn't use it in JAMES product because #1 SetupBuilder was commercial and #2 it required our release manager to run on windows in order to create the instealler. He pointed me that APache HTTPD has a windows installer based on a commercial product too (Installshield). Can you kindly give more details on how you dealt with this? Apache projects only release source. The binary installer is just one of many post-release, binary builds that are created by trusted individuals and delivered by us in order to make our non-programming users happy. The ASF does not vote on them (release them), and we don't need them to be entirely based on open source because the contents are not source. They just have to be redistributable as binaries under our license. Roy
Re: about httpd installer
Roy T. Fielding wrote: On Aug 3, 2008, at 9:19 AM, Stefano Bagnara wrote: I'm a PMC member of the Apache JAMES project. We received a contribution from an user including an installer for our main product (Apache JAMES Server). The installer is for the Windows platform and is created using a commercial product named SetupBuilder. I pointed the user that we couldn't use it in JAMES product because #1 SetupBuilder was commercial and #2 it required our release manager to run on windows in order to create the instealler. He pointed me that APache HTTPD has a windows installer based on a commercial product too (Installshield). Can you kindly give more details on how you dealt with this? Apache projects only release source. The binary installer is just one of many post-release, binary builds that are created by trusted individuals and delivered by us in order to make our non-programming users happy. The ASF does not vote on them (release them), and we don't need them to be entirely based on open source because the contents are not source. They just have to be redistributable as binaries under our license. Precisely. I'll add though, that if you can do it from scratch, the obvious way in this day and age is to start with the WIX project (sourceforge, MS created) which is an XML format - very transparent, and can be built by any of the contributors using free tools. That's actually my roadmap for apr (httpd etc). The nice bit of WIX, you can build using whatever-tool, and then export the .msi into WIX's format as a starting point. That's your project's call, obviously. What ASF had released is Source Code, as Roy points out, everything else is commentary. Bill
