Thomas
On Sun, 2010-02-21 at 09:17 +0100, Thomas Koch wrote:
> However, since I'm currently doing mostly PHP and web
> development I'm faced day by day with "just-good-enough" "solutions".
> And it annoys me. These kind of solutions mostly solve your current problem
> quickly and without much investment. However, once you've installed them and
> want to add additional functionality you get hit by the poor design of the
> software.
This is where I think you're not really appreciating the way people are
expected to deploy this application in commercial use. We expect people
to create their websites using either the template site we provide as a
basis, or by designing their own pages and then merely adding the WACS
API calls into what they've created in Dreamweaver or whatever.
If you take a look at the Wacs-PHP Simple Skin you will find a set of
PHP end-user presentation apps that are significantly implemented in the
way you suggest. The content and the styling are totally separate and
the CSS file laid out in such a way as to make relatively easy to style.
It's extensively commented to try to make it easier for a web programmer
to understand what is going on.
There's a very significant 120 page Programming Guide that includes a
step-by-step tutorial, a full API reference manual detailing all the
calls, return value and purpose, and a full database schema along with
guidance on the predefined values that are implicitly expected by the
underlying code. There are also various tutorial examples that show how
code using the API is progressively built up.
Web developers are dealing with a straight forward, thoroughly
documented API provided in two different languages but with (almost)
exactly the same semantics.
> Then poor web developers get forced to spend hours hacking spaghetti code and
> making the whole thing worse with every added feature.
I'd be very surprised indeed if most developers using WACS would ever
get involved with the basic toolset code. It's not part of the end user
delivery chain at all. It's merely there to provide an administrative
GUI to the underlying database.
> Yes. I think, many times it's better not to have anything at all instead of a
> bad solution that gives you the false impression of a solved problem.
Understood. I think you're getting a false impression of the package by
focusing on the back-of-house collection database management tools which
are not part of the delivery chain.
> However I think, that your software may serve as a good prototype.
Absolutely. Effectively that is what it provides from the viewpoint of
the web developer. It's totally modular. Other than the database
schema and the API, there's nothing that you have to use. You can
maintain the entire collection using SQL or the command line tools if
you want to. Everything to enable you to do that is described in the
documentation.
If you don't like the Web GUI for database maintenance, you can use the
CLI instead. If you don't like the CLI, you can use SQL and the shell.
The architecture is both open and extensively documented.
> I'm just not convinced, that users benefit from its inclusion in Debian:
Users find software through packages listed in their distribution's
catalog. Very, very few seek it outside of that framework. Those that
do find themselves with all kind of version/revision issues and
problems.
Past and present experience of the support requests for WACS show very
clearly that it is the subtle differences between distributions that
cause well over 90% of the problems for users. The best way to address
that is to make the package part of distributions so that the users can
be assured that the two will work together. Right now we directly
support and provide packages for the current releases of Fedora and
Ubuntu and we're working on getting the package into those distributions
too.
> - One version of the software must be maintained (security bugfixes) during
> the whole lifetime of a Debian stable release, which may be something between
> 2,5-3,5 years. The upstream code will most likely change a lot during this
> time, however the Debian maintainer still must fix years old code.
Absolutely - that is one of the major points of being a Linux
distribution. This is one of the reasons why we've not been talking to
the Debian project about this package until six years into the
development of the project. We wanted to make sure that we had a
credible level of maturity and stability before we made these
approaches.
> - Once Debian moves forward to a new stable version, you must provide the
> Debian stable users with an easy migration path to the newest version. The
> upstream code (database schemes) may have made several migrations during this
> time, which you must somehow script in one version upgrade path.
Yes, that is one of my problems as a developer. We have our first major
schema changes in nearly three years coming up in WACS 0.8.5, and none
of those will be mandatory until at least the WACS 0.9.x series. We
always introduce schema changes a full release cycle before we make use
of them - that's always been policy.
We will be providing a migration path or making sure the code functions
correctly with the old schema, but that will not be strictly relevant
for the Debian packaging of WACS 0.8.5 or later as it is unlikely to
change again for some time. Never-the-less, the commitment is there.
> - Users that want to try your software and just issue an apt-get install wacs
> will get an outdated version of your software and may not realize, that you've
> a much better, newer version on your webpage.
Yes, this is situation normal. But if the older release works for them,
then that is fine. We're making this approach now because we're pretty
confident that the WACS 0.8.5 baseline that we're releasing next month
will form the basis of the platform for the foreseeable future. The
schema changes that this release incorporates are the condensed result
of issues our development work has highlighted over the last three
years.
> So it's not only arrogant snobism about software quality from my side but it
> may also be in your very own interest, not to invest in maintaining a Debian
> package at this time.
I do not feel it is appropriate for me to maintain the Debian version of
this package. I thought I made that clear at the outset. There are
sufficient considerations due to the content that what is included and
what is not should be subject to the checks-and-balances of being
reviewed by someone else. I would consider the debian community very
ill-advised if they expected me to do this work.
I've been too close to the adult industry for too long to consider my
perspectives on acceptability to reflect those of all the members of
society that Debian might wish to engage with.
> Remember, that the first two points from the list above
> require manpower, that is therefor not available for upstream development.
Understood. Right now, WACS is heading from a rapid development cycle
into a more stable release cycle with fewer changes expected. This is
why we're choosing this moment to work on getting packages into
distributions where we can.
> I've once been involved in eGroupWare, which gained most of it popularity from
> it's very easy automatic web installer:
> - download, untar in your web servers dir
> - open http://yourserver/install.php
If only that would work. The reality is that our extensive dependencies
make it virtually impossible to auto-install on a new platform that we
haven't seen before.
This morning I've had a bug report that indicates that Debian Lenny
doesn't successfully run our Ubuntu 9.10 .deb packages, whereas it did
on run just fine on previous Debian releases.
We're obviously working on getting a fix for that user but it just
emphasizes to me how important it is that we integrate tighter with the
distributions and don't leave it to the end users to bear the brunt of
distribution upgrade incompatibilities. Anyone doing even basic testing
on Debian Lenny would have found the problem (it's IPv6 related).
However as a software developer I can't track every release from every
distribution, and without the distribution providing us with support in
terms of testing, indexing and promoting our application, the reality is
that fewer distributions will be supported and more users will hit
distribution related problems.
> You'll gain much more user satisfaction from such an installer then from a
> Debian package.
Unfortunately this has not proven to be the case - it has caused more
user dis-satisfaction than all other parts of the system put together.
Initially we had a generic installer based approach, but have been
forced to relegate it to port of last resort because the dependency
matrix is just too complex. At this point I am considering removing the
installer completely as I think it's unlikely to be able to resolve all
the issues it encounters on a new platform.
> Such an installer also works for Windows, Mac and other Linux
> distros.
Not a snowball's chance in hell, unfortunately. We used to support Macs
but when we found that the dependency build process was taking more than
six hours to complete and that that caused a hardware failure on our
MacBook due to overheating, we reluctantly had to drop support for Macs.
We did not want to endanger user's computers and packaging up all the
components we needed at the revision levels we needed was taking too
much time away from core code development.
> Once this installer gained you a bigger user (and developer)
> community and your project has matured enough, somebody from the developers
> will step and package it for it's distro of choice.
That's what we'd hoped initially. The reality has become that we've
gone from believing we were a Linux and MacOS X application to realising
that we're a Fedora 10-12 and Ubuntu 8.10-9.10 application at this
point. Anything else just isn't that likely to work.
Why? The main problem areas are (in order of severity) PAM
Authentication, HTTP server configuration methodologies, IP layer
configuration, Perl and PHP module packaging and package naming
conventions.
> Therefor it's not a requirement, but a very good indicator, if the upstream
> developer and the Debian packager are distinct persion: It means, that the
> project is popular enough, that somebody else then the creator had the urge to
> package it.
And it may be that Debian will have to be placed on the unsupported list
in the same way that MacOS X has been. I don't see that as a desirable
scenario - some people will choose not to use WACS and won't gain the
benefits of using it, others will choose to cease using Debian. Given
the lack of alternatives in the market place if the role to be fulfilled
by WACS is mission-critical to the user, it may well be that Debian
looses out. I don't want to see that happen.
The reality is if I'm investing the time and money in a third supported
platform it will be an Enterprise platform like RHEL or OpenSolaris
where the likelihood of a financial return from a commercial support or
consultancy contract is significantly higher.
So I'm hoping someone here or on the debian-mentors list will decide to
get involved. This is an upstream developer holding out a hand and
saying "come help me and together we can fulfill the needs of a whole
new group of users". If the answer is "no, we don't care" then we all
loose out.
Cheers
Beaky
--
To UNSUBSCRIBE, email to debian-webapps-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@kennedy.bevteccom.co.uk