Re: TC voting and amendment procedure
On Tue, Nov 27, 2007 at 07:36:30PM +, Ian Jackson wrote: But it does suggest that we ought to do formally proposing resolutions and amendments by writing draft CFVs. A draft ballot paper would give dissenters a chance to add their own option, with short or long explanatory text as needed. FWIW, this was a factor in my failure to vote, which was effectively a time-starved further discussion by abstention. The constitution may allow any one of us to call for a vote without any minimum discussion period, but that doesn't mean I think it's a very effective way to carry out business; especially for complex issues such as this one, I think we need to have a good idea of what the consensus is first and call the vote only when we think we're ready to ratify that position. In the present case neither of the non-FD options are satisfactory to me because as I wrote in [EMAIL PROTECTED], I think rationale here is very important. There's no question in my mind that it's wrong to standardize on RFC3484 s 6 rule 9 for IPv4 addresses, but overriding the Debian maintainers without a coherent plan to get this addressed at the IETF level would to my mind be something of a Pyrrhic victory, solving the immediate problem with the Debian mirrors and similar infrastructure but saddling the glibc maintainers with a delta indefinitely. And a recommendation to the IETF is going to count for more if it comes with a rationale than if it's four (or however many) people voting that the rule should be ignored without even being able to agree on the nature of the problem. At present I remain optimistic that we can reach a consensus on a document that incorporates everyone's concerns, which is why I think further discussion is worthwhile. However, in light of the current rate of progress on this bug, if we can agree informally that this is in principle what we should do I'm willing to be persuaded to postponing the rationale to a separate vote. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mixmaster /etc/default/*
On Sun, 02 Dec 2007, Anthony Towns wrote: On Fri, Nov 30, 2007 at 06:40:36PM -0800, Don Armstrong wrote: Deciding that an issue isn't important enough to make a decision requires making some sort of decision. No it doesn't, it just requires not noticing an issue -- eg, by it not being brought to the tech ctte's attention at all (most decisions in Debian), or by the tech ctte missing it when it is (429761, 439006), or by the tech ctte leaving it lie (436096). These are all recent bugs, so presumably they can raised again by whoever thought originally that they were important. That's exactly wrong for the committee -- we should be around to work on hard problems, and we shouldn't be spending any time at all on the easy ones, which maintainers are already dealing with. I don't think the current case is an example of the committee looking for problems to resolve on it's own. Someone disagreed with the maintainer, and brought the issue to the tech-ctte. The tech-ctte makes a decision, either by deciding to override, not override, FDing to death, or ignoring entirely, the latter three being largely the same outcome. Furthermore, it seems counterproductive to complain about a decision on a trivial issue being a waste of time by prolonging the discussion of a trivial issue. [From my seat in the stands, this is also what appears to have occured in whatever remains for the RFC 3484 decision as well... but perhaps that's merely a case of incomplete communication.] Don Armstrong -- We were at a chinese resturant. He was yelling at the waitress because there was a typo in his fortune cookie. -- hugh macleod http://www.gapingvoid.com/batch31.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mixmaster /etc/default/*
On Fri, Nov 30, 2007 at 07:38:00PM +, Ian Jackson wrote: Having read the bug report I don't think there is very much to be said in favour of the submitter's point of view. Here is a draft resolution and rationale. -8- (1) The REMAIL option should not be supplanted or supplemented by anything in an /etc/default file. The current behaviour of the mixmaster init script, to examine /etc/mixmaster/remailer.conf's REMAIL option, is correct. (2) Policy is clear and correct, and need not be changed. -8- [ ] Choice K: Keep current behaviour and existing policy, as above. [ ] Choice F: Further discussion I'm happy to vote on this; for once it looks like we have a bug that's easy to close out ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee ping
On Tue, Nov 27, 2007 at 07:14:23PM +, Ian Jackson wrote: Please reply to if you get this email and let us know whether you are in a position to transact TC business. We seem to have a problem getting quorum and I'd like to know why. Pong. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: setting package to tech-ctte, severity of 438179 is normal, tagging 438179, tagging 441200
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.10 package tech-ctte Ignoring bugs not assigned to: tech-ctte severity 438179 normal Bug#438179: Please provide a way to override RFC3484 Severity set to `normal' from `wishlist' tags 438179 + confirmed Bug#438179: Please provide a way to override RFC3484 There were no tags set. Tags added: confirmed tags 441200 + confirmed Bug#441200: libconfig name clash There were no tags set. Tags added: confirmed End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#441200: libconfig name clash
On Thu, Nov 29, 2007 at 08:15:47PM +, Ian Jackson wrote: So just to be clear, you conclude as I did that both packages should be required to select new names ? Yes. I can't see any technical reason whatsoever not to do that. If either maintainer *wants* to use a different package name, they should just upload it to NEW, and the technical committee shouldn't even consider being involved unless there's an actual dispute about that name. The problem is that without at least some controls the maintainers are quite likely to pick poor replacement names. We've had at least one of them propose `libconfig1' which I'm sure you'd agree is bad. Huh? That just seems daft -- it's not a different name at all, it's just the package name for libconfig with a .so version of 1... I can't see any record of anyone suggesting that though, and I'd really hope that it wouldn't be accepted at NEW. Abraham, Julien, do you have sensible alternative names for your packages (eg, incorporating the existing libconfig into the libabz package, or renaming the new libconfig package to libconfig-hyperrealm)? If so, what are they? One option would be for the TC to explicitly ask the ftpmasters to be especially fussy with the replacement names. For example: N. The Committee asks the ftpmasters, when they process the resulting packages from either maintainer through NEW, to ensure that the new names are clear, descriptive, and unlikely to cause further clashes. I would have thought this was already the case for _all_ packages, and that libdebug and libconfig being accepted in the first place under those names was a mistake. It's a bit long ago to really review now though. I don't support the technical committee being involved unless there's a clear lead; and even if I'd otherwise support the resolution, I'll vote against it if it tries to expand the technical committees influence where it's not clearly needed. I'm not sure what you mean by `clear lead'. Perhaps you mean `clear need'. Yes. I don't have a problem with restricting the scope of the decisive part of the TC's formal ruling, provided that we can come up with some way to avoid the substitute names being just as poor. I'm afraid I'm struggling with incredulity that we even need to deal with that... NEW processing should deal with it, and the maintainers involved should be able to figure out that libconfig1 isn't going to work... In any event, the way I currently see this is: (2) The existing libdebug in Debian must be renamed or removed. You're suggesting overruling the maintainer of this package, I take it. Sorry, I meant this is what I think, not this is what I think the tech ctte should rule.The libdebug package has way too general a name. (3) The existing libconfig and libdebug should be incorporated into libabz. I would be happy to recommend this as formal part of our decision but I don't think we would want to overrule the maintainer. No, hence the should instead of must. (4) The proposed libconfig should be called libconfig-hyperrealm or similar to distinguish it from other libconfigs. I agree with this. How do you think we should word this part of our decision to make it clear what we mean ? See above. If we have to choose a name (and can't rely on NEW processing or the maintainers to work how they're supposed to), I'm inclined to think we should just pick some ourselves. Cheers, aj signature.asc Description: Digital signature
Old tech-ctte bugs
Hey all, No one on the ctte seems to have taken any interest in: * #429671: exim4 username * #436093: Please decide on the ownership of the developers reference * #439006: tech-ctte: Efika and sony PS3 patches in linux-2.6 They're all requests for dispute resolution, though 429671 also includes a request from the exim4 maintainer for a final decision on namespacing policy for packages that need usernames from the package maintainer. They're all between three and five months old. I think it's better to send a response to the submitter and maintainers involved than just leave them hanging; so unless someone on the ctte thinks there's something that warrants ctte's review in any of those reports and wants to take ownership of making that happen over the next week or so, I'll close them under the assumption we're going to let the maintainers' decisions stand, at least for the forseeable future. (If you do want to take ownership of one, tagging it confirmed seems a useful way to distinguish reports that the ctte hasn't indicated an interest in. Please don't take ownership of something and let it just continue to sit there, at least an independent analysis for the rest of us would be a good start...) Cheers, aj signature.asc Description: Digital signature
Re: mixmaster /etc/default/*
Anthony Towns writes (Re: mixmaster /etc/default/*): No, I'm saying that we shouldn't be in the business of reviewing every disagreement in Debian. And we certainly shouldn't leave the decision as to whether we'll review any particular decision solely up to whether whoever was disagreed with is unwilling to let the matter drop. That is precisely what our job is. We expect our co-developers and users to use some sensible judgement. If this turns out to be a problem then we can develop some lightweight way of getting rid of nuisance questions. But there doesn't seem to be a big problem here. The submitter's not wrong in any important way -- if he were the maintainer and had decided to take the course of action, that'd be fine too. I disagree with that. I'm not sure I'd personally want to push the question to the TC under those conditions but if someone else did so I would be willing to issue a ruling saying that the maintainer was doing the wrong thing. Uh, the bug never actually got reopened or reassigned to the ctte, and the submitter's most recent mail said I'm fine with the result. What's the point of a vote? You appear to be referring to Jari's mail of 01 Dec 2007 19:34:58 +0200. I think the result he's saying is fine is the version of his request represented in Peter Palfrader's summary. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
* Marc Haber: On Sat, Dec 01, 2007 at 07:34:58PM +0200, Jari Aalto wrote: From Admin's point of view dealing with symlinks is much more uncomfortable to control the initial start/stop status. If one is not comfortable with a sysvinit scheme, one should not be adminning a Debian system. Alternatives (such as file-rc) are available, and while update-rc.d is strictly speaking only geared to be used from maintainer scripts, it can also be used as a tool for the local admin. Really? Won't upgrades re-enable disabled services if update-rc.d is used? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Old tech-ctte bugs
Anthony Towns writes (Old tech-ctte bugs): * #429671: exim4 username * #436093: Please decide on the ownership of the developers reference * #439006: tech-ctte: Efika and sony PS3 patches in linux-2.6 They're all requests for dispute resolution, though 429671 also includes a request from the exim4 maintainer for a final decision on namespacing policy for packages that need usernames from the package maintainer. They're all between three and five months old. I think it's better to send a response to the submitter and maintainers involved than just leave them hanging; so unless someone on the ctte thinks there's something that warrants ctte's review in any of those reports and wants to take ownership of making that happen over the next week or so, I'll close them under the assumption we're going to let the maintainers' decisions stand, at least for the forseeable future. Please do not do that. (If you do want to take ownership of one, tagging it confirmed seems a useful way to distinguish reports that the ctte hasn't indicated an interest in. Please don't take ownership of something and let it just continue to sit there, at least an independent analysis for the rest of us would be a good start...) As you may be aware, my lifestyle has changed somewhat and I have a good deal more time to deal with this kind of thing than I used to. I plan to take an ongoing interest in all decisions which are referred to the TC and left undone. We currently have enough decisions on our plate awaiting disposal but we should get on with the others and I will see to it that we deal with them. I have to say though that we aren't going to be able to do our job if we spend all of our time doing things like: * Voting Further Discussion and then not discussing the matter * Arguing about the detailed contents of rationales rather than about the substance of our ruling * Arguing about whether to deal with things rather than dealing with them * Failing to vote at all Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#441200: libconfig name clash
Anthony Towns writes (Re: Bug#441200: libconfig name clash): I can't see any record of anyone suggesting [libconfig1] though, and I'd really hope that it wouldn't be accepted at NEW. See #438683 where otherwise sensible people are suggesting using the name libconfig1 for the new library due to the TC's inactivity. Abraham, Julien, do you have sensible alternative names for your packages (eg, incorporating the existing libconfig into the libabz package, or renaming the new libconfig package to libconfig-hyperrealm)? If so, what are they? I think we need to decide this issue without allowing ourselves to be diverted into protracted negotiations with the maintainers. One option would be for the TC to explicitly ask the ftpmasters to be especially fussy with the replacement names. For example: N. The Committee asks the ftpmasters, when they process the resulting packages from either maintainer through NEW, to ensure that the new names are clear, descriptive, and unlikely to cause further clashes. I would have thought this was already the case for _all_ packages, and that libdebug and libconfig being accepted in the first place under those names was a mistake. It's a bit long ago to really review now though. Yes, it is too late to go back and understand how this mistake was made. I just want to make sure that the problem actually gets solved - ie, that the same mistake is not made again. Since we know that this mistake can be made, I think we should take steps which are likely to prevent it. Can I persuade you about that clause ? (4) The proposed libconfig should be called libconfig-hyperrealm or similar to distinguish it from other libconfigs. I agree with this. How do you think we should word this part of our decision to make it clear what we mean ? See above. If we have to choose a name (and can't rely on NEW processing or the maintainers to work how they're supposed to), I'm inclined to think we should just pick some ourselves. I would be happy with us simply issuing advice to the ftpmasters for their NEW processing. Would you be happy with such a clause ? I see that you think it's unnecessary but the art of politics is compromise. If you don't think it's harmful and I think it's necessary, are you willing to see it included ? Picking names ourselves is going to make us deeply unpopular (rightly so IMO) and get us well bogged down in bikeshedding. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Call for Votes (Re: mixmaster /etc/default/*)
I hereby call for a vote on the resolution below, which I sent round a draft of on Friday and formally proposed yesterday: -8- (1) The REMAIL option should not be supplanted or supplemented by anything in an /etc/default file. The current behaviour of the mixmaster init script, to examine /etc/mixmaster/remailer.conf's REMAIL option, is correct. (2) Policy is clear and correct, and need not be changed. -8- [ ] Choice K: Keep current behaviour and existing policy, as above. [ ] Choice F: Further discussion My vote is: [1] Choice K: Keep current behaviour and existing policy, as above. [2] Choice F: Further discussion 1. As very helpfully summarised by Peter Palfrader, the current situation is as follows: o The mixmaster package provides both the client and server functionality. o By default the server part (running a remailer) is not enabled. o To configure mixmaster to run as a remailer the admin has to set a dozen options in /etc/mixmaster/remailer.conf. Options like email address, which formats they will accept, whether to run as an exit or only as a middleman remailer, etc. o One of those options is the REMAIL setting, which enables or disables the remailing (server) part of mixmaster. o The init script has code to only try starting the mixmaster daemon, which is only needed when it's being run as a remailer, when the REMAIL option is actually set to y in that config file. 2. The submitter has requested that instead of checking /etc/mixmaster/remailer.conf for REMAIL being set to `y', the init script should read a new setting out of a file in /etc/default. 3. The submitter relies on this part of policy 9.3.2: Often there are some variables in the init.d scripts whose values control the behavior of the scripts, and which a system administrator is likely to want to change. As the scripts themselves are frequently conffiles, modifying them requires that the administrator merge in their changes each time the package is upgraded and the conffile changes. To ease the burden on the system administrator, such configurable values should not be placed directly in the script. Instead, they should be placed in a file in /etc/default, which typically will have the same base name as the init.d script. This extra file should be sourced by the script when the script runs. [...] 4. The committee's role is not to interpret policy; rather our role includes both determining the appropriate behaviour in a specific case and also to specify the appropriate policy wording. However, we should make our decisions based on the all of the available information, and existing policy documents are a useful input to that process. 5. The purpose of this section of policy is admirably and clearly stated by the policy itself. The intent is that an administrator who wishes to make a commonly-made change to the behaviour of an init script will be able to edit the file in /etc/default rather than the script itself. The point of this is that when the package maintainer improves the script (which happens often), the administrator only needs to do a trivial merge of the /etc/default file rather than to deal with a conffile prompt due to the changes to the script itself. 6. I agree with the policy as stated, and find the wording clear. There is little room for improvement. I wholeheartedly adopt the principles and rationale described in the policy text, as a good basis for the rest of my reasoning. 7. The present situation does not match that described in the policy. The setting in question, whether to run the daemon, is not recorded in the init.d script but rather in a different configuration file. There is no need to edit the init.d script to enable or disable the daemon. So the reasoning described in the policy does not apply directly. 8. But we should consider whether an analogous argument can be made. The reasoning in the policy text could apply to other configuration files which contain a good deal of complex text supplied by the package maintainer, and where certain changes might want to be made by many administrators. In those circumstances it would be useful to move those commonly-modified configuration options into a separate file for the same reasons as one wishes to movoe commonly-modified settings out of init.d scripts. 9. If that were the case then a file in /etc/default might be a good choice, depending on implementation language and other details. (For example, in my opinion files in /etc/default ought to be shell scripts as described in 9.3.2, and if for implementation reasons the new small configuration file wasn't a shell script then it ought not to be in /etc/default; also, not all such shell script configuration fragments
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
Florian Weimer writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): Really? Won't upgrades re-enable disabled services if update-rc.d is used? Only if you delete _all_ of the links. If you leave the K links in the shutdown and reboot runlevels, they will not be put back. This ought to be documented somewhere ... Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
On Sun, Dec 02, 2007 at 10:10:38PM +, Ian Jackson wrote: Florian Weimer writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): Really? Won't upgrades re-enable disabled services if update-rc.d is used? Only if you delete _all_ of the links. If you leave the K links in the shutdown and reboot runlevels, they will not be put back. This ought to be documented somewhere ... It is documented in the update-rc.d manpage: If any files /etc/rcrunlevel.d/[SK]??name already exist then update- rc.d does nothing. The program was written this way so that it will never change an existing configuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
Kurt Roeckx writes (Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)): It is documented in the update-rc.d manpage: If any files /etc/rcrunlevel.d/[SK]??name already exist then update- rc.d does nothing. The program was written this way so that it will never change an existing configuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. That's good of course but the sysadmin who's messing about in /etc and is not familiar with Debian is not likely to even have heard of update-rc.d. Perhaps it should be in a README somewhere nearby. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TC voting and amendment procedure
On Sun, Dec 02, 2007 at 09:49:54PM +, Ian Jackson wrote: Everyone (even AJ, it seems) agrees that glibc in sid and lenny should be changed immediately. No, I have not seen any reason to overrule the maintainers in this entire thread. I don't see how I could have indicated that any more clearly than I already have. Despite repeatedly suggesting that some actual reports from admins who've been affected might sway my view, I haven't seen anyone even trying to come up with any. Our current rate of progress is approximately zero. Better than heading speedily in the wrong direction. Cheers, aj signature.asc Description: Digital signature
Re: TC voting and amendment procedure
On Mon, Dec 03, 2007 at 01:26:16PM +1000, Anthony Towns wrote: On Sun, Dec 02, 2007 at 09:49:54PM +, Ian Jackson wrote: Everyone (even AJ, it seems) agrees that glibc in sid and lenny should be changed immediately. No, I have not seen any reason to overrule the maintainers in this entire thread. I don't see how I could have indicated that any more clearly than I already have. Despite repeatedly suggesting that some actual reports from admins who've been affected might sway my view, I haven't seen anyone even trying to come up with any. In what way are the reports that this has adversely affected Debian mirrors unsatisfactory? If there's specific information from the mirror operators that would help you, by all means let's try to get it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
