Bug#167513: the lack of consultation or discussion regardingthis change is not good
> > I also note the irony in Thom expressing his great displeasure at not
> > being involved in the discussion that led to the policy change and yet
> > this is something that "all 3 of [you]" have been discussing and didn't
> > choose to involve me.
>
> Since we are 3 person involved as Apache Maintainers I don't see anything
> strange in discussing each bug report between us, and still i believe
> people should stop pointing the finger at Thom, since he was just
> answering in the name of Tollef Fog Heen, himself and me as "Debian Apache
> Maintainers <debian-apache@lists.debian.org>"
There's nothing wrong. It's just ironic. Thom complained about use
not consulting you when talking policy and then he (and you) discuss it
all between yourselves without consulting me. I'm not singling anybody
out; the mail came from Thom so I use his name not wishing to put words
in your mouth. I was not even aware, originally, that there were multiple
maintainers for Apache.
> > > I don't know how many of you have considered the fact that atm Debian
> > > ships 507 cgi scripts, in 115 pkgs, only in /usr/lib/cgi-bin WITHOUT
> > > considering other pkgs that can refer to them or their config files and so
> > > on.
> >
> > I'm well aware of the difficulties. I'm also aware that there was little
> > thought put in to this placement in the first place, which is why we're
> > now faced with an ever growing problem.
> >
> > I'm trying to minimize the impact by keeping cgi-bin where it was for now,
> > so the transition is a smooth one. If you want to make the argument that
> > even new installations should keep cgi-bin in the traditional place for
> > this release, then make that case.
>
> Speaking as myself now, without wearing the apache maintainer hat, you
> still don't see the impact this will have to users upgrading from woody to
> woody+X. The transition can be smooth from sid to sid because it can be
> coordinated during the time. A user that will upgrade from woody will get
> all the transition in one shot. No matter what we do in our scripts.
> Adding an alias just because the installation is already there can make it
> but the user will never feel the benefit of this change. Without
> considering that he/she will have to modify all custom scripts to match
> the new standard if he/she wants to benefits from it.
An individual user doesn't need to feel the benefit of the change for it
to be a benefit to other users and a benefit in general. It may even
be a benefit to the user who didn't notice it at some point in the future
when that person wants to use "/cgi-bin/" in their own scripts.
> > It could be changed to <webroot>/cgi-bin
> > once the majority of packages have made the conversion.
>
> > Right now we have a fundamental problem that Debian goes against the
> > established mechanism of allowing webmasters to use /cgi-bin/, or at
> > least we must give up debian package scripts to do so.
>
> Still not wearing my apache maintainer hat, i never allow webmasters or
> web contents managers to install directly their own cgi. Specially in big
> environments where more than one person has rw access to the web contents.
> Thinking of systems like Contribute or shared maintainance.
That's your choice. It should be your choice. Right now, it's not your
choice or my choice. That's my point.
> > > Are you dealing to test and fix all of them if needed?
> >
> > This is not really a difficult change. It's pretty much a global search &
> > replace of "cgi-bin" to "cgi-lib" for packages that use that in their URLs.
>
> Back wearing my apache maintainer hat. this is far away to be enough. As a
> DD I have learned to test as much as i can before uploading a package as
> well testing packages that depends on mine. Yes you can say that I am
> paranoid but that's what keeps high quality in Debian.
> And you should know this much better than i do since you were a Release
> Manager for Debian.
I wish more people were as thurough as you. Being thurough, however, does
not mean making no changes or correcting problems.
I've very consious of the potential problems which is why I tried to come
up with a series of steps such that there would be little if any negative
impact on users who just expect their system to "work".
> > But, because of the slow change-over of existing /cgi-bin/ to the proper
> > location (only new installations would do that), any instances that are
> > missed or done incorrectly will onlyaffect a small number of users, all
> > of which are using new installations anyway and should be expecting such
> > things.
>
> So basically we should do all this to have only a few users benefit the
> change and watching their system broken for a certain amount of time
> during the transition phase? Because if only new installation will really
> gain something out of it than sorry.. it is useless..
> old installation would have to be changed manually since it is impossible
> to automate the process.
The point of the steps is that nothing will get broken. Both the old and
new mechanisms will continue to work during all upgrades. It's only new
installations that may have a period of unstability, but that is why we
have an "unstable" release in the first place. By the time it goes to
"stable" and thus is suitable for the unwashed masses, most if not all
of the packages should have been corrected.
And, if this isn't good enough, I don't see a problem with continuing to
installing /cgi-bin/ as pointing to the same place it does now until each
and every package is up to date. Then even brand new installations would
always work without a hitch. However, I don't feel this is necessary
because we should be able to correct all the packages (all 115 of them)
in the time between now and the next major release.
> > > I don't really see the advantage of such a change compared to the amount
> > > of work that needs to be done in order to implement it.
> >
> > It is a lot of changes, but they're mostly, if not completely, just small
> > changes and distributed over a large number of maintainers.
>
> I referred to the "change" in its globality. Of course they are a lot of
> small changes all over the place and that's why i placed some numbers in
> my previous email. imho the balance of "what we gain"/"effort" does not
> worth the change.
I guess I'm missing something because I don't see what the big effort is.
- The amount of effort necessary within Apache is small.
- The amount of effort within any given package is small, perhaps even tiny.
The benefit is a system where admins have the ability to give webmasters
access to their traditional /cgi-bin/ location without being interferred
with by system packages.
I think the benfits outweigh the effort.
Brian
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
Many times the difference between failure and success is doing something
nearly right... or doing it exactly right.
Reply to: