Re: please vote...
On 9 Aug 1999, Manoj Srivastava wrote:
> Hi,
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
>
> Dale> Asside from the user having to look in two places during the
> Dale> "transition" what things break if no symlinks are provided? So
> Dale> far I've heard suggestions that package helper scripts will
> Dale> fail because they don't know about the new location. I submit
> Dale> that, under the current policy these scripts are broken, should
> Dale> be bug reported, and should be fixed to comply with
>
> You did not hear that in the proposal. And you are correct,
> that is a silly reason.
What I heard in the proposal was that without the symlinks "things break".
The only "things" that I know of that break are the helper tools and
checker programs. If these are "silly reasons", then your argument that
things break is silly, unless you can provide evidence of more important
breakage.
>
> Dale> policy...whatever that resolves itself to be. If we are going
> Dale> to allow helper tools to stand in the way of progress, then
> Dale> what kind of help are they anyway? The tools should be improved
> Dale> to handle transition situations like this, rather than
> Dale> requiring global package mods to support the tools through the
> Dale> transition.
>
> This is a red herring.
No, this is exactly the kettle of fish you wish to us to stew in. The
policy group has made a faulty change to policy, and now you want us to
correct that failure by forcing the acceptance of a new policy to fix the
old, broken, policy change.
>
> Dale> Basicly it looks to me like the policy group got the cart
> Dale> before the horse, and mandated conformance without determining
> Dale> any process for the transition. Now the Technical committee is
> Dale> being asked to choose between an unacceptable design and no
> Dale> design in order to resolve the problems greated by the
> Dale> previously, not well thought out, policy change.
>
> This is not the forum to damn the policy list. We are being
> asked to rule on a proposal.
>
A proposal that would be unnecessary if the policy group were acting in a
responsible fashion, and making reasonable changes to the policy
statements.
> >> From my point of view this is not a technical problem, but a political one
> Dale> within the policy group that can only be resolved there.
>
> Dale> Manoj, you are asking that we force approval of a proposal that
> Dale> the policy group appears unwilling to pass. There is _no_
>
> So?
>
This is not in our mandate. We are NOT a policy making arm of this
organization.
> Dale> alternative being proposed by the "opposing side" for the
> Dale> Technical commitee to evaluate, dispite the attempt on your
> Dale> part to outline an alternative.
>
> Where does it say there have to be more than one proposal for
> the tech ctte to choose? Chapter and verse please.
>
We are a deadlock resolution mechanism, not a policy dictator.
> Dale> Finally, Manoj, although I know that this committee is not
> Dale> supposed to become involved in designing solutions, I _must_
> Dale> ask why the obvious solution has not been explored? Mainly
> Dale> modifying the helper packages to handle the transition
> Dale> difficulties. Unless you can give me a different kind of
> Dale> failure, it seems to me that this is the obvious place to
> Dale> perform the fix. Give developers a time scale for the
> Dale> transition, and give the "checker" programs the skill to check
> Dale> both places. After all packages meet the new location standard,
> Dale> the checker programs can "stiffen" their conditions to only
> Dale> accept the new state of affairs.
>
> Because in the opinion of the majority, and given our track
> record, the transition shall not happen in a release interval
>
Were else does it happen? Your statement doesn't reply to my comments.
> Dale> In addition, I have heard the argument that requiring all
> Dale> packages to move before the potato release would be
> Dale> impossible. This is a fairly simple fix. I don't use "helpers"
>
> I think you are unduly optimistic.
I have not accurately described the difficulty of the change?
It is no more complex than changing /usr/doc to /usr/share/doc in the
appropriate locations in my rules files. How hard _is_ that?
>
> Dale> in my packages, and I can't see this taking more than 5 minutes
> Dale> per package to impliment. The only "penalty" we would face
> Dale> would be the "massive" uploads of new packages (note that
> Dale> almost no new source uploads would be required), just before
> Dale> the "freeze". On the other hand, it would be a reasonable way
> Dale> to "filter" out a large number of packages based on a simple
> Dale> issue...can you make the transition before the deadline or
> Dale> not. If the package makes the deadline, it is included in the
> Dale> next release, if it doesn't then it will wait for the next
> Dale> release. This just might get the distribution down to a
> Dale> reasonable size ;-) but I suspect that the number of packages
> Dale> that "couldn't" make the deadline would be surprisingly
> Dale> small. (I _must_ be a "prophet" ;-)
>
> Prophets are often wrong.
>
So?
> Dale> Anyway, if it isn't clear by now, I stronly suggest that this
> Dale> is not a properly formed question for this committee to get
> Dale> involved with.
>
> I disagree. The constituion is clear on this point.
>
The constitution does not force us to vote on your proposal. We all agreed
during the preliminary discussion that the committee could easily reject
any proposal it thought flawed or otherwise improper.
> Dale> Either come back with two proposals,
>
> Justify that request. You may have to have the constituion
> changed while you are at it.
The constitution has nothing to do with this. This committee can make any
requirements of the proposers that it deems necessary.
>
> Dale> thoughtfully argued and presented, or resolve this issue
> Dale> through a vote of the membership. Without at least two
> Dale> proposals to choose from, there is nothing for this committee
> Dale> to decide.
>
> Rubbish. Please read the constituion before making remarks
> like that.
>
The constitution is _very_ clear. This committee WILL NOT DO DESIGN WORK!
Wichert, in his proposal asked this committee to do just that. Your
proposal has done little to provide us with alternatives.
We are being asked to authorise a single proposal against the wishes of
the existing body designated to make such decissions. You seem totally
unwilling to provide any justification for your proposal, only suggesting
that I have missed the point whenever I try to get you to provide such
justification.
If you want me to support this proposal you are going to have to go quite
a bit farther than you have so far at describing the underlying desperate
need that requires this committee's involvement in the decission. Calling
me stupid just doesn't get it.
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Reply to: