Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi, Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago On 10 Aug 1999, Manoj Srivastava wrote: Hi, Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago If we followed this rule of only object in extreme circumstances, Santiago we could be drawing circles forever. See: On the contrary, if every one objected formally all the time we shall never resolve anything. Santiago This has not happened in this case. We decided to switch Santiago from FSSTND to FHS, which includes switching from /usr/doc Santiago to /usr/share/doc, and nobody objected, so we had a Santiago consensus. We made a general, sweeping, policy decision, to adopt the FHS. The detail, it was expected, would be worked out. We also said that not all details of the FHS may be adopted (/var/state is one that comes to mind). We are now working the details out. Santiago This issue is already resolved by current policy, which Santiago says to use /usr/share/doc, with no special symlinks or Santiago anything. No. The policy says no such thing. Show me, the paragraph, where it says that. Not mentioning symlinks in no way prohibits them Santiago I don't have any special model of doing things. I just Santiago think that we reached a consensus when we decided to switch Santiago from /usr/doc to /usr/share/doc. We are not rescinding that. Santiago Now some people want to break the consensus and go back to Santiago /usr/doc, and I consider this as a bad thing, because it Santiago breaks a previous consensus. That's all. I think you are mistaken. The people merely want to defer the timetable for that particular move. The original decision to adopt the FHS did not do anymore than set a tentative timetable, and the timing details can be defined by subsequent proposals, like this one. Santiago If you think current policy procedures are unacceptable, Santiago please amend them. I don't think it is necessary. I think we do need to specify some additional guidelines for using the veto. Overfrequent (note: I did not say frivoulous) use of the veto shall shackle this group, since that would require near unanimity, rather than the 75% super majority we agreed to when we adopted the guidelines. I think that the current attitude of intellectual intolerance (I *must be right, and everyone else is obvioulsy wrong) would make the policy list ineffective. Santiago The policy list is still effective for dealing with Santiago technical issues, and I hope it will continue to be. I think we can be more than that. I think that we should be able to pass amendments that may even be unpalatable to some people. Requiring us to please all the people on the list all the time would make it impossible to achieve anything in here. Santiago This issue, however, seems not to be very technical but Santiago quite subjective. I wonder if the *technical* commitee has Santiago really something to say about this. Ask them. Yo have the right, after all. manoj -- Proposed Additions to the PDP-11 Instruction Set: BBW Branch Both Ways BEW Branch Either Way BBBF Branch on Bit Bucket Full BH Branch and Hang BMR Branch Multiple Registers BOB Branch On Bug BPO Branch on Power Off BST Backspace and Stretch Tape CDS Condense and Destroy System CLBR Clobber Register CLBRI Clobber Register Immediately CM Circulate Memory CMFRM Come From -- essential for truly structured programming CPPR Crumple Printer Paper and Rip CRN Convert to Roman Numerals Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On 15 Aug 1999, Manoj Srivastava wrote: Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago This has not happened in this case. We decided to switch Santiago from FSSTND to FHS, which includes switching from /usr/doc Santiago to /usr/share/doc, and nobody objected, so we had a Santiago consensus. We made a general, sweeping, policy decision, to adopt the FHS. The detail, it was expected, would be worked out. We also said that not all details of the FHS may be adopted (/var/state is one that comes to mind). We are now working the details out. Well, you say that we made a general policy decision to adopt the FHS, but the fact is that policy was patched to read /usr/share/doc everywhere instead of /usr/doc. This does not seem like a little detail to me. Santiago This issue is already resolved by current policy, which Santiago says to use /usr/share/doc, with no special symlinks or Santiago anything. No. The policy says no such thing. Show me, the paragraph, where it says that. About /usr/share/doc: There are lots of paragraphs talking about /usr/share/doc, I don't think we need to quote them. About symlinks: see below. Not mentioning symlinks in no way prohibits them You may be mixing different things here. I thought we were discussing about this proposal (the one in bug #42477, i.e. /usr/doc vs /usr/share/doc). You seem to be talking about /usr/share/doc with symlinks vs /usr/share/doc without symlinks. Santiago I don't have any special model of doing things. I just Santiago think that we reached a consensus when we decided to switch Santiago from /usr/doc to /usr/share/doc. We are not rescinding that. I think we are. Santiago Now some people want to break the consensus and go back to Santiago /usr/doc, and I consider this as a bad thing, because it Santiago breaks a previous consensus. That's all. I think you are mistaken. The people merely want to defer the timetable for that particular move. The original decision to adopt the FHS did not do anymore than set a tentative timetable, and the timing details can be defined by subsequent proposals, like this one. I thought that policy was policy, not tentative policy. The way I read your words it almost seems that someone has to present a proposal and get seconds to keep things as they are (i.e. use /usr/share/doc without requiring symlinks). Santiago If you think current policy procedures are unacceptable, Santiago please amend them. I don't think it is necessary. I think we do need to specify some additional guidelines for using the veto. Overfrequent (note: I did not say frivoulous) use of the veto shall shackle this group, since that would require near unanimity, rather than the 75% super majority we agreed to when we adopted the guidelines. If we go back to /usr/doc, I will be tempted to use the word frivolous for the previous policy amendment that switched from /usr/doc to /usr/share/doc some weeks ago. I think policy matters should be treated more seriously than that, and going back to /usr/doc would be a bad precedent. I think that the current attitude of intellectual intolerance (I *must be right, and everyone else is obvioulsy wrong) would make the policy list ineffective. Santiago The policy list is still effective for dealing with Santiago technical issues, and I hope it will continue to be. I think we can be more than that. I think that we should be able to pass amendments that may even be unpalatable to some people. For example, the symlink forrest on a per package basis? ;-) Requiring us to please all the people on the list all the time would make it impossible to achieve anything in here. I wish you were a little bit more optimistic. I think the procedure for amending policy (proposed by you, btw :-) has worked very well so far, and I'm very glad of that. impossible to achieve anything? The reality I see is very different. Thanks. -- 75ec58b08ad1131a4cb235931704baa5 (a truly random sig)
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On 6 Aug 1999, Manoj Srivastava wrote: Remco == Remco Blaakmeer [EMAIL PROTECTED] writes: Remco Then, if this really good scheme is agreed upon, the whole Remco transition can be done between the potato release and the Remco release after potato. In my opinion (looking back that the libc5, libc6 moves, and looking at the growing number of packages), that is unjustifiable optimism. I don't think we can indeed move all packages in one release interval. The libc5 - libc6 transition was far more difficult than this one. People had to cope with code incompatibilities, different library dependencies, etc., etc. In this case, the transition is (or should be) very simple for almost all packages. The number of developers is growing at about the same rate as the number of packages, so I don't think the amount of effort needed per developer is higher than in previous transitions. If the transition scheme is agreed upon before potato is released, developers will have a lot of time to do the transition. I think it is rediculous that you can't even ask for each package to be uploaded at least once between two consecutive releases. For all these reasons, I don't think my optimism is as unjustifiable as you think it is. Remco -- rd1936: 12:05am up 59 days, 15:01, 5 users, load average: 1.30, 1.23, 1.19
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On 10 Aug 1999, Manoj Srivastava wrote: Hi, Santiago == Santiago Vila [EMAIL PROTECTED] writes: Santiago If we followed this rule of only object in extreme circumstances, Santiago we could be drawing circles forever. See: On the contrary, if every one objected formally all the time we shall never resolve anything. This has not happened in this case. We decided to switch from FSSTND to FHS, which includes switching from /usr/doc to /usr/share/doc, and nobody objected, so we had a consensus. This issue is already resolved by current policy, which says to use /usr/share/doc, with no special symlinks or anything. The moethod right now talks about, if there was no consensus, to call for a supermajority vote of 75%. Under you model of doing thnigs, votes shall never be required -- either everyone agrees, or if 4 people do not like vene one part of the proposal, it dies. I think that is unacceptable. I don't have any special model of doing things. I just think that we reached a consensus when we decided to switch from /usr/doc to /usr/share/doc. Now some people want to break the consensus and go back to /usr/doc, and I consider this as a bad thing, because it breaks a previous consensus. That's all. If you think current policy procedures are unacceptable, please amend them. I don't think it is necessary. I think we do need to exercise restraint in formal objections. If you are so sure that you are right, it should not be hard to convinve the others of your views. If you can't, then may be you are indeed the one whoi is ``wrong''. Well, this particular issue seems to be a matter of (subjective) opinion, more than an issue of being right or wrong. Examples: - I think that mixing /usr/doc and /usr/share/doc is ugly - I think that mixing /usr/doc and /usr/share/doc is not so ugly. - I think potato should be consistent. - I don't think mixing /usr/doc and /usr/share/doc will make potato to be inconsistent. - potato will be frozen very soon - potato will not be frozen very soon. I think that the current attitude of intellectual intolerance (I *must be right, and everyone else is obvioulsy wrong) would make the policy list ineffective. The policy list is still effective for dealing with technical issues, and I hope it will continue to be. This issue, however, seems not to be very technical but quite subjective. I wonder if the *technical* commitee has really something to say about this. Thanks. -- f67164dd8e28e231344e187266927c61 (a truly random sig)
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On Tue, Aug 10, 1999 at 02:01:08PM +0200, Santiago Vila wrote: On Mon, 9 Aug 1999, Anthony Towns wrote: [...] formal objections are only appropriate in extreme circumstances. 1. Someone propose to abandon /usr/share/doc in potato and go back to /usr/doc. Two advocates of using /usr/doc in potato second the proposal. Since this is not extremely important, people is afraid of making formal objections and the proposal is accepted, and policy is modified. 2. Later, someone propose to abandon /usr/doc and use /usr/share/doc instead. Two advocates of /usr/share/doc in potato second the proposal. Since this is not extremely important, people is afraid of making formal objections and the proposal is accepted, and policy is modified accordingly. There's no need to be afraid of making formal objections. It's an extreme measure, that's not generally necessary. The reason that it's not generally necessary is that an *ordinary* objection, where you just post and say I think this is stupid, or I think the other idea is better and give reasons. Then you argue, and try to reach a mutually acceptable conclusion. While you're still arguing, then consensus hasn't been reached. After you've finished arguing, you've presumably found common ground, or at the very least found out whether -policy generally thinks your objections are worth considering, in which case either consensus has been reached, and you agree with it even, or there's an obvious problem that has to be fixed with the proposal and everyone else is aware of it. Personally, I think the problem with this is that the distinction between an ordinary objection and a formal one isn't particularly obvious. The former is just part of the cut and thrust of debate, whereas the latter cuts of debate entirely, and says that the issue being discussed is beyond the scope of the -policy list. Do you want a technical objection? I have objected to this proposal because I don't see any technical flaw in *current* policy which justifies changing it. Which is perfectly reasonable. On the other hand, numerous other people have posted saying that they *do* have a problem with current policy, and that not having all the /usr/doc stuff accessible from a single directory is annoying. Just because you're not in that group of people who'll benefit from this doesn't mean you ought to demand that they go away and leave you alone. OTOH, technical objections like this solution will break dpkg or doing this would mean we'd have 5000 extra maintainer scripts hanging around for the rest of eternity are certainly relevant. I think this should be enough, and should not be considered the end of the world. As Manoj has pointed out, the policy procedures were not designed to deal with highly controversial issues like this one. We need the policy procedures to be that way so that things are approved by consensus. Feh. The only reason we've had problems dealing with this is because none of us really knew how the new -policy proposal guide worked, and when to use formal objections, and when not to. That the ideal solutions generally tickled bugs in dpkg and next to no one had any idea exactly what the actual results of most of the ideas would be didn't help matters either. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgptuYNlR0xoD.pgp Description: PGP signature
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Mike Goldman [EMAIL PROTECTED] writes: Furthermore, it is clear that the proposal was not at all serious, but a measure intended only to buy time. Excuse me? It was most definitely *both*! And moreover, to give us a clean release of Potato, and to give us an entire release cycle to get Woody into shape. I don't hold much hope in the deus ex machina magic solutions -- while it's true that the proposal *does* allow us more time to consider such solutions, that was most *assuredly* not the purpose of the proposal. A serious proposal should provide the implementation and timing for the transition to take place, and not defer such decisions to some future time. The timing was exact: Potato uses /usr/doc, everything subsequent uses /usr/share/doc. I don't know how much more exact you want, especially since when I made the proposal, we didn't have a target freeze date for Potato yet. The implementation was precise and simple: again, Potato uses /usr/doc, everything subsequent uses /usr/share/doc. What's missing from that implementation? The really interesting thing is that the day before I made the proposal, you said explicitly that you would support such a proposal. You are one of the people I had on my list of obvious seconds. And yet, when I actually made the formal proposal, you suddenly decide that it's evil and horrid. And pose some very strange, and, frankly, obscure objections. Forgive me for being confused, but I am. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On Mon, 9 Aug 1999, Anthony Towns wrote: [...] formal objections are only appropriate in extreme circumstances. This is an interesting comment. I think there are several kinds of policy proposals: 1. Those who add new rules in policy to be followed. 2. Those who modify already existing rules in policy. This proposal is clearly of the second kind. I don't think that proposals of the second kind should always need extreme circumstances to be formally objected. If we followed this rule of only object in extreme circumstances, we could be drawing circles forever. See: 1. Someone propose to abandon /usr/share/doc in potato and go back to /usr/doc. Two advocates of using /usr/doc in potato second the proposal. Since this is not extremely important, people is afraid of making formal objections and the proposal is accepted, and policy is modified. 2. Later, someone propose to abandon /usr/doc and use /usr/share/doc instead. Two advocates of /usr/share/doc in potato second the proposal. Since this is not extremely important, people is afraid of making formal objections and the proposal is accepted, and policy is modified accordingly. 3. The same guy who proposed to abandon /usr/share/doc proposes it once more and gets two seconds... This would clearly lead us to nowhere. Do you want a technical objection? I have objected to this proposal because I don't see any technical flaw in *current* policy which justifies changing it. I think this should be enough, and should not be considered the end of the world. As Manoj has pointed out, the policy procedures were not designed to deal with highly controversial issues like this one. We need the policy procedures to be that way so that things are approved by consensus. Thanks. -- 7a28a241942854c426140402103a25e7 (a truly random sig)
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Chris Waters wrote: I have a couple of things to say about this proposal. I think that we have a bad track record when it comes to merely deferring the issue until a latter date This proposal defers nothing. It merely mandates a *delay* for the transition. Granted, it does leave room for someone to come up with a deus ex machina solution to the migration (i.e. a working patch to dpkg that magically fixes everything, and which IWJ loves), but it doesn't rely on any such thing. It's very simple. Potato continues to use /usr/doc, Woody and beyond use /usr/share/doc. No fuss, no muss. I disagree. Your proposal would have been very worthwhile if made *before* the new Policy was adopted, and *before* lintian began complaining about files in /usr/doc. Okay, maybe it was premature, and it was a bad idea at the time, and so forth. But the fact is, most developers do *not* read -policy, they read Policy, and hopefully pay attention to lintian. There is no requirement or even expectation that -policy be monitored for disputes. So the fact is, many packages, some of which are very large, and thus time consuming to build and upload, have been converted to the FHS /usr/share/doc. To tell the developers of these packages that, through no fault of their own, they must rebuild and reupload, not once, but twice, first to move *back* to /usr/doc, and later forward to /usr/share/doc again, is serious muss and fuss indeed! My withdrawal of formal objection aside, I still consider this a *seriously* misguided proposal, and an unnecessary one. Moving (automatically) to /usr/share/doc is just not that hard IMNSHO. If the Technical Committee resolves to stay with /usr/doc as you've proposed, I think it would be a mistake, but I will comply. I hope they will consider my recommendation to simply use an automatic migration script to simply move noncompliant packages to the appropriate FHS location, leaving a README in /usr/doc for our users.
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
[not cc'ed to the bug report] On Sun, Aug 08, 1999 at 05:04:01PM -0400, Mike Goldman wrote: Richard Braakman wrote: Mike Goldman wrote: Therefore, I formally object to this proposal. You have given reasons for not liking the proposal, but no reasons for it being unviable. I think a formal objection is far too strong. I think it is both undesirable and unnecessary, neither by themselves sufficient for a formal objection perhaps, but together very much objectionable. Just because a proposal is objectionable doesn't mean that it's appropriate to formally object to it or (equivalently) call for a hold on it. The way we're treating formal objections is more along the lines of You guys all suck. I'm taking my bat and my ball and going home. rather than Look, cricket sucks. Calvinball is much much much cooler. We really should play that. Alternate proposals, and acidic rants about how stupid proposals and proposers are all very well, but formal objections are only appropriate in extreme circumstances. This is a step backwards is daft, but it's not that extreme. BTW, please keep your line lengths around 75 characters rather than around 80 so they can be quoted conveniently. Just my two cents. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgpihpN3ML5nC.pgp Description: PGP signature
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi, Chris == Chris Waters [EMAIL PROTECTED] writes: Secondly, I think that the policy should not hard code release names Chris I would call this a serious flaw in policy then. My opinion is a flaw in policy? ;-) Chris I think we NEED a way to say, these are the rules for release Chris X, these are the rules to follow subsequently. Ideally, I Chris think we'd have a strategy document that takes precedence over Chris policy, but that's a fairly major proposal, one that I'm a Chris long, *long* way from proposing formally. :-) Think about adding a layer of abstraction. I would rather couch your example above as These are the rules that need be follwed right now. (footnote: at a latter point policy may be amended to follow these other rules). That leaves us some leeway to decide when to make the changes, and allows us to reflect upon and change the ``other rules'' to reflect any changes in the situation. It also does not tie us down to a particular release frame (the project may decide to have an e,ergency woody release two weeks after potato -- not very likely, but why close doors we need not?) Chris The way this was handled in the symlink proposal (leaving the Chris cleanup to an unspecified future policy change which may or Chris may not ever happen) strikes me as a *really* awful way to Chris handle this. Far better to just allow the proposal to specify Chris which parts apply to which releases if it's important to do so Chris (as it is with these proposals). I think the loss of flexibility is not worth the gains. Of course, I may be missing some of the gains, since all you say is that your opinion is that this is a really awful way, but give no rationale (at best, the gain is that you feel better about the proposal, but that is not really a satisfactory reason for me). At a latter date, policy can be changed to reflect that the move is kosher. Chris I think this is much worse than hard coding release names in Could you give some reasons? Chris policy. Though I agree that neither is *ideal*. But there's Chris only so much that can be done today. Either we institute Chris temporary policy with *no* markings and *assume*[1] that we'll Chris fix it later, or we clearly mark it as temporary policy when Chris we all know that it is temporary policy. I think the latter Chris is *far* preferable. We can mark it as a temporary policy. We just leave the end of the temporary period open, to allow us to set the time when we are closer to the change, and to change what needs be done if the circumstances change (dpkg may get revamped, for example). manoj -- Fortune Documents the Great Legal Decisions: We think that we may take judicial notice of the fact that the term bitch may imply some feeling of endearment when applied to a female of the canine species but that it is seldom, if ever, so used when applied to a female of the human race. Coming as it did, reasonably close on the heels of two revolver shots directed at the person of whom it was probably used, we think it carries every reasonable implication of ill-will toward that person. Smith v. Moran, 193 N.E. 2d 466. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
[a second followup to cover one point more accurately, and to add some details to another] Manoj Srivastava [EMAIL PROTECTED] writes: I have a couple of things to say about this proposal. I think that we have a bad track record when it comes to merely deferring the issue until a latter date This proposal defers nothing. It merely mandates a *delay* for the transition. Granted, it does leave room for someone to come up with a deus ex machina solution to the migration (i.e. a working patch to dpkg that magically fixes everything, and which IWJ loves), but it doesn't rely on any such thing. It's very simple. Potato continues to use /usr/doc, Woody and beyond use /usr/share/doc. No fuss, no muss. Secondly, I think that the policy should not hard code release names I would call this a serious flaw in policy then. I think we NEED a way to say, these are the rules for release X, these are the rules to follow subsequently. Ideally, I think we'd have a strategy document that takes precedence over policy, but that's a fairly major proposal, one that I'm a long, *long* way from proposing formally. :-) The way this was handled in the symlink proposal (leaving the cleanup to an unspecified future policy change which may or may not ever happen) strikes me as a *really* awful way to handle this. Far better to just allow the proposal to specify which parts apply to which releases if it's important to do so (as it is with these proposals). At a latter date, policy can be changed to reflect that the move is kosher. I think this is much worse than hard coding release names in policy. Though I agree that neither is *ideal*. But there's only so much that can be done today. Either we institute temporary policy with *no* markings and *assume*[1] that we'll fix it later, or we clearly mark it as temporary policy when we all know that it is temporary policy. I think the latter is *far* preferable. [1] and you know what they say about assumptions -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi, Chris == Chris Waters [EMAIL PROTECTED] writes: Chris Manoj Srivastava [EMAIL PROTECTED] writes: I have a couple of things to say about this proposal. I think that we have a bad track record when it comes to merely deferring the issue until a latter date (I point to the archive reorg issue Chris Which is a political issue. We're bad at political issues -- we're Chris good at technical ones. This one is a technical one. I think you arte thinking of the wrong reorg. The reorg I am talking about was a technical solution to the huge number of release critical bugs and the delays they entail -- it would have created an incrementally updated stable pool of packages. That was deferred, and is lost in the mists now. Secondly, I think that the policy should not hard code release names, we should just say that we are moving to the FHS, with a few Chris I STRONGLY disagree. If policy can't mention release names, Chris then we should create a formal strategy, which defines the Chris future direction of policy. We *need* to be able to plan for Chris the future, for situations like this. If policy continues to Chris ignore the release cycle, then ugly messes like this are just Chris going to arise again and again. You can do all the planning without naming the code names. Chris A static policy may have been adequate when the system was Chris originally being built, and there was no release cycle, but Chris now that it's built, we need to start planning for *change* Chris instead of assuming that the system will be static for Chris eternity. I think you are very confused. There was never a case when there was no release cycle. And a strategy for change does not need to be encapsulated in policy (though in this case I think we can indeed encapsulate the changes without naming the release code name. Chris I'm guessing that there's just about zero chance that Santiago will Chris withdraw his objections to either proposal. All the objections need not be withdrawn -- we just need one person. Finally, the tech ctte may come forth with a proposed transition; the DPL has asked the ctte to consider this problem. Chris As long as they have *all* the facts, and are aware of my proposal as Chris well as the bletcherous mandatory symlink proposal, fine. And as long Chris as they're aware of NEW objections to the ghastly mandatory symlink Chris proposal, like the requirement to add postinsts to all the packages Chris that currently lack them, possibly for eternity, certainly till at Chris least Woody+2 or +3 (which I wasn't aware of until *after* the Chris proposal was already mooted). bletcherous? ghastly? This _is_ a technical discussion we are having, right? (using emotionally laden words like that does littel for credibility). In any case, the ctte is far from unapprochable. If unbiased reporting is much of a concern to you, just write to [EMAIL PROTECTED] The list is also archived, so you can have a look at what is being said. manoj -- Anything free is worth what you pay for it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On Thu, Aug 05, 1999 at 03:54:49PM +0100, Julian Gilbey wrote: Wusses. :-) Huh? What does that mean? Hasn't anybody ever seen Beavis and Butt-head? -- G. Branden Robinson |I have a truly elegant proof of the Debian GNU/Linux |above, but it is too long to fit into [EMAIL PROTECTED] |this .signature file. cartoon.ecn.purdue.edu/~branden/ | pgpAdxZQxaBeO.pgp Description: PGP signature
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Marcus Brinkmann [EMAIL PROTECTED] writes: That you consider your proposal primary as an alternative to be considered by a committee that only steps in if the policy group fails is also something that worries me a lot. Well, don't worry then, that's not primary, that's just a backup plan. A worst-case scenario. And the rest of your logic falls apart, since it hinges on the ridiculous theory that I didn't make this proposal because it was the solution I wanted to see implemented. So, do you actually have any comments about the PROPOSAL? cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Hi, Remco == Remco Blaakmeer [EMAIL PROTECTED] writes: Remco The advantage of this proposal is that it buys time. Time to Remco come up with a really good transition scheme. I am not sure that merely postponing the transition is likely to enable us to come to a conesnsus on a ``really good scheme''. Chances are, that this shall be dropped in favour of other release critical issues, and we shall be back in woody development, with no tnagible changes. (Look at what happened to the archive reorg debates -- the pool of packages and staging area proposals). Remco Then, if this really good scheme is agreed upon, the whole Remco transition can be done between the potato release and the Remco release after potato. In my opinion (looking back that the libc5, libc6 moves, and looking at the growing number of packages), that is unjustifiable optimism. I don't think we can indeed move all packages in one release interval. Remco That way, potato doesn't need to be released as a half-way Remco converted system. I thik at least one release shall have to be done in a transition state. Frankly, I thik we should be able to handle it. Remco Or do you want all packages to use /usr/share/doc in potato Remco already? Again, IMHO, that is not practical. manoj -- Let me do my TRIBUTE to FISHNET STOCKINGS ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Manoj Srivastava [EMAIL PROTECTED] writes: I have a couple of things to say about this proposal. I think that we have a bad track record when it comes to merely deferring the issue until a latter date (I point to the archive reorg issue Which is a political issue. We're bad at political issues -- we're good at technical ones. This one is a technical one. We've got some people saying that we can actually complete the transition before POTATO gets released, and other saying that if we delay, we won't be able to complete before WOODY. I think both extremes are wrong. Secondly, I think that the policy should not hard code release names, we should just say that we are moving to the FHS, with a few I STRONGLY disagree. If policy can't mention release names, then we should create a formal strategy, which defines the future direction of policy. We *need* to be able to plan for the future, for situations like this. If policy continues to ignore the release cycle, then ugly messes like this are just going to arise again and again. A static policy may have been adequate when the system was originally being built, and there was no release cycle, but now that it's built, we need to start planning for *change* instead of assuming that the system will be static for eternity. Strategy should take precedence over policy. Policy should be for immediate, here-and-now questions, and Strategy should be for where are we going, and how are we going to get there issues. However, I think this is a step backwards, we still have time to set up a transition, and I think this proposal is premature (especially as people are talking about withdrawing formal objections to the symlink proposal). If the objections are withdrawn, we shall be once more in the running. I'm guessing that there's just about zero chance that Santiago will withdraw his objections to either proposal. Finally, the tech ctte may come forth with a proposed transition; the DPL has asked the ctte to consider this problem. As long as they have *all* the facts, and are aware of my proposal as well as the bletcherous mandatory symlink proposal, fine. And as long as they're aware of NEW objections to the ghastly mandatory symlink proposal, like the requirement to add postinsts to all the packages that currently lack them, possibly for eternity, certainly till at least Woody+2 or +3 (which I wasn't aware of until *after* the proposal was already mooted). -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
Julian == Julian Gilbey [EMAIL PROTECTED] writes: /usr/doc whereever this document refers to + /usr/share/doc./p Julian Seconded. Wusses. :-) netgod JCommons Debianism [DEH-BEE-IN-ISIM] /n./ An open source (GPL'd) religion founded on the beliefs of the GNU-GPL
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On Thu, Aug 05, 1999 at 15:54:49 +0100, Julian Gilbey wrote: Wusses. :-) Huh? What does that mean? wuss is US slang for wimp or perhaps coward. What netgod probably means is that this proposal is basically a cop-out, postponing the work until after potato's release. I agree with that, but the powers that be regrettably do not seem to be on my side. Ray -- Tevens ben ik van mening dat Nederland overdekt dient te worden.
Re: Bug#42477: [PROPOSED} delay the /usr/doc transition till after potato
On Wed, 4 Aug 1999, Chris Waters wrote: Therefore, I propose that Packages intended for for the distributions code-named Potato (and Slink) continue to use /usr/doc. This will ensure that Potato is consistent. Plus, this gives us an entire release cycle to find a smooth transition path. And to finish dealing with *other* FHS issues, so we really *do* have an FHS-compliant system. Yes, this seems to be the best thing to do for potato. Now, for the transition, there are basically two scenarios: 1) Every package just moves the files from /usr/doc to /usr/share/doc. 2) There is some method to assure that new packages will work on old systems, with all their dependencies satisfied. ad 1): This is, of course, the simplest way to do things. The only thing that is required for this, is that there is at least one upload of every package between two consecutive releases. One big drawback is that people installing 'potato+1' packages on potato (or slink, or ...) systems will not find the documentation easily. ad 2): This is the way Debian seems to be heading right now. People want to have compatibility between different releases, and that's good. But how many releases are really supported? There are many packages with no dependencies at all. Those are mostly documentation packages, like packaging-manual and gimp-manual. If I want to take one of those packages from Debian 2.6 (or whatever) an install it on a Debian 2.0 (or 1.1, or whatever) system, will it still behave the right way? My point here is, a really smooth transition will likely be a burden on _all_ packages, for ever. One of the simplest ways to achieve 2) is made impossible because dpkg screws up. I have a package that Debian decided to drop because of license issues. I thought, I'd make a new version of it using /usr/share/doc instead of /usr/doc and install it. I decided to add in a symlink '/usr/doc/package - ../share/doc/package', too, for compatibility. When I installed this package, dpkg didn't install the symlink, though, it just left the directory /usr/doc/package in place, which was now empty. BTW, I think the first issue that should be sorted out is how much compatibility there should be between a release and all its predecessors. The outcome of this debate will greatly effect the issue of which method to achieve this compatibility is best. Remco -- rd1936: 6:50pm up 49 days, 9:46, 7 users, load average: 1.09, 1.10, 1.10
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On Thu, 5 Aug 1999, J.H.M. Dassen (Ray) wrote: wuss is US slang for wimp or perhaps coward. What netgod probably means is that this proposal is basically a cop-out, postponing the work until after potato's release. I agree with that, but the powers that be regrettably do not seem to be on my side. The advantage of this proposal is that it buys time. Time to come up with a really good transition scheme. Then, if this really good scheme is agreed upon, the whole transition can be done between the potato release and the release after potato. That way, potato doesn't need to be released as a half-way converted system. Or do you want all packages to use /usr/share/doc in potato already? Remco -- rd1936: 9:25pm up 49 days, 12:21, 7 users, load average: 1.20, 1.21, 1.13
Re: Bug#42477: PROPOSED} delay the /usr/doc transition till after potato
On Thu, Aug 05, 1999 at 05:14:37PM +0200, J.H.M. Dassen Ray wrote: Wusses. :-) Huh? What does that mean? wuss is US slang for wimp or perhaps coward. What netgod probably means is that this proposal is basically a cop-out, postponing the work until after potato's release. I agree with that, but the powers that be regrettably do not seem to be on my side. I agree with it. = Not that I'm a power or anything, but I agree all the same. -- Joseph Carter [EMAIL PROTECTED] Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -- Never underestimate the power of human stupidity. -- Robert A. Heinlein pgpTdQDTG5Nse.pgp Description: PGP signature
