Bug#167513: the lack of consultation or discussion regarding this change is not good
On Wed, 7 May 2003, Brian White wrote:
> > Seriously. We have been discussing this issue all 3 of us and we agreed
> > that we will not implement this change until a proper discussion will take
> > place where both users and developers are involved. Thom was only
> > spreading our voice around so addressing him directly is not proper imho.
>
> Just to be accurate... I brought this idea to the apache maintainer(s)
> when I first had it and got a general reply of "don't bother us with this
> until it's policy". So, away I went.
We read the entire thread as reported by you and we know the story from
what is written in the here: http://bugs.debian.org/32263
> 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>"
> > 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.
> 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.
> > 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.
> 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.
> > 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.
Regards
Fabio
--
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues
http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp00004.html
Reply to: