Other modules in the early phase of incubation that looks promesing like mod_ftp might end up having simular fates!
Is placing interesing modules like mod_aspdotnet, mod_ftp,... in a seperated project a good idea?
Maybe they live longer if there where part of the httpd-truck?
Jorge
On 7/19/06, William A. Rowe, Jr. <
[EMAIL PROTECTED]> wrote:
Summary;
+1 binding: wrowe
+1 nonbinding feedback (with qualitative data) from:
Jorge Schrauwen
James Park (pencil_ethics)
Trent Nelson
As none of the other pmc members care to inspect the source tarball, the
vote fails. As Roy has raised concerns about httpd's ongoing ownership,
even of the prior release, that too will be removed from the active
www.apache.org/dist/httpd/mod_aspdotnet location. archive.apache.org is
a lovely permanent museum for that wrinkle in time (2.0.0.2000 21 Nov 2004).
As 2.0.4 and the various snapshots between now and then are not releases,
those have been removed from /dev/dist. It will take me a few days to find
the free cycles to expunge the trunk of httpd/docs/manual/, downloads.cgi,
etc and then remove /dist/httpd/mod_aspdotnet.
As there is no oversight going on here, no further commits will occur to
bring mod_aspdotnet to Visual Studio 2005 here.
What does the list want to do with the unreleased mod_arm4 and mod_aspdotnet
code repositories? Do we want to create a /repos/asf/httpd/attic/ repository
for abandoned/orphaned httpd code? Or simply svn rm them, knowing they still
persist at certain points in history and can be resurrected?
To those disappointed, I share your disappointment, but have no regret. This
is what it is. I have spent considerable time reviewing the history of posts
to cli-dev, cli-users, and the bugtraq database. No specific individuals
stand out as frequent posters of bug fixes (not that many were needed), peer
to peer user feedback authors etc. Obviously one solution would be to draft the
few that express an interest here and now, but the httpd project (appropriately)
expects a reasonable track record to avoid exactly this sort of issue.
Although this was a rather mature module from it's inception, with a very short
list of issues that users wanted addressed, it certainly attracts many more
users than developers. The net code changes since it was granted two years ago
are less than 250 LoC, and developing -within- the framework has much more
interest than developing the -module-, itself.
I'm afraid this is no different than the passing of JRun and other similar, now
abandoned code. Developers and their technologies move on. It would be amusing
if the project spent 5% of the effort that's invested in Apache 1.3 to review
this release, but that wasn't to be.
Sadly yours,
Bill
William A. Rowe, Jr. wrote:
> Build 2004 of mod_aspdotnet is prepared (after a number of abortive
> attempts due to the whole 2.0/2.2 partitioning and renaming of apache.exe,
> along with switching flavors of InstallShield to a version I have
> installed)
> and seeking voters. The update is here;
>
> http://httpd.apache.org/dev/dist/mod_aspdotnet/
>
> Please cast your +/- 1's to release mod_aspdotnet-2.x.0.2004-source.zip
> (along with associated binaries ...2.0.0.2004.msi and ...2.2.0.2004.msi,
> one corresponding to 2.0.44 and later, the other to 2.2.2 and later).
>
> This is the last expected release on the Visual Studio .NET (al la 2002)
> compiler toolchain; the next effort is porting it to VS 2005 (al la, the
> one available in a free flavor). Porting breaks compatibility with the
> older tools, since VS 2005's C++.NET schema is miles beyond 2002. For
> example, a reference becomes a reference, not an overloaded psuedo-pointer.
>
> Bill
>
> .
>
--
~Jorge
