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]
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: Bug#441200: libconfig name clash
On Sun, Dec 02, 2007 at 10:00:31PM +, Ian Jackson wrote:
> 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.
#438683 has a new maintainer who hasn't passed T&S or P&P and who isn't
otherwise involved in the ITP suggesting it as above, and Martin Michlmayr
retitling the bug so his scripts are more accurate:
] I'll retitle the bug for now since it messe up my script that check
] for consistency of WNPP bugs. (libconfig exists already in the
] archive, so it thinks this ITP should be closed).
I don't find that remotely concerning or particularly relevant.
> I think we need to decide this issue without allowing ourselves to be
> diverted into protracted negotiations with the maintainers.
> 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.
So we shouldn't be involved in negotiations -- even to the extent of
asking maintainers where they stand; shouldn't pick anything particular
ourselves, and should practice the art of politics by compromising? All
over a name that hasn't even been suggested by any of the packagers?
Cheers,
aj
signature.asc
Description: Digital signature
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: 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]
Bug#441200: libconfig name clash
Here's my latest draft of a libconfig resolution. No-one seems to be suggesting that either package is entitled to the name so I have removed that option. Thanks to AJ for detailed feedback. I've taken out the process for the TC approving names and replaced it with a request to the ftpmasters. I've also made the process clearer, by ensuring that inactivity by the existing libconfig maintainer would not block the removal of the old-named package. I've added a recommendation about libdebug, and one about other distros. If those latter two prove controversial they can come out again. Ian. -8<- To the maintainers and ftpmasters: (1) The existing libconfig in Debian must be renamed or removed. The ftpmasters should remove it from sid right away; the maintainer may upload a renamed version (but see (4) below). Any packages in sid which depend on libconfig and remain unfixed within 4 weeks should also be removed from sid. (2) The newer library may not use the name libconfig either. To the ftpmasters: (3) When the renamed packages from either maintainer are processed through NEW, please ensure that the new names are clear, descriptive, and unlikely to cause further clashes. For example, libconfig-hyperrealm would be a good name which distinguishes the library under ITP from other libconfigs. `libconfig1' is not an acceptable replacement name. To the libdebug maintainer: (4) We recomment that the current libdebug in Debian should also be renamed or removed, for example by folding both it and the existing libconfig into libabz. To other Linux distributors, and to the ITPer: (5) We recommend that Mark Lindner's libconfig should be packaged in Linux under a more descriptive name, preferably one agreed by the parties and accepted in Debian. We encourage the Debian maintainer to take responsibility for these negotiations. -8<- NB THIS IS A DRAFT BALLOT - THERE HAS NOT YET BEEN A CFV [ ] Choice N: Neither package may use the name `libconfig' [ ] Choice F: Further discussion 1. This is a dispute about who should be allowed to use the name `libconfig' (both as a library name as in -lconfig and in the package name). 2. The existing libconfig in Debian (`the existing library') is old, not widely used (has no reverse dependencies) and has only 40 installations listed in popcon. It is packaged as a Debian-native package. 3. The alternative is a newer more widely-used C++ library from an external author, which has existed for some time. (`The newer library'.) 4. `config' is not a very distinctive name. Just as we do not like command names which are simple words or the most common abbreviations thereof, we do not like simple undistinctive library names like `libconfig'. 5. A web search for `libconfig' gets references to the newer library but also many references to 5 other libraries called libconfig (both published libraries and private parts of publicly distributed projects). Basis for deciding 6. There are several possible considerations which might guide us when resolving a name clash: 7. The most obvious is the balance of convenience. Which way will produce the least overall problems given the situation we currently find ourselves with ? 8. We must in my opinion also consider whether the name is more appropriate or relevant to one program or the other. 9. However, as a decisionmaking body we should also encourage good practice in general . To do otherwise would give namespace landgrabbers carte blance to create `facts on the ground' (as is sometimes said in international relations). (1) Good practice includes choosing a distinctive and appropriate name in the first place. However in cases of a conflict the two groups will typically already have failed to do so. But, good practice would also often include: (2) Paying attention to documentation and policies which ought to have influenced the choice of name; (3) Choosing a long and unique name for what is likely to be a program of narrow, specialised or local interest. (4) Searching for existing uses of a name before committing to it. (5) Ensuring that one's name, once chosen, will show up in such searches and/or paying attention to possible future conflicts if feasible. This isn't an exhaustive list. 10. We should in my opinion balance these three kinds of considerations. 11. We are, I think, entitled to decide that neither intended user is entitled to the name. We should have regard to all of the above factors in this case, and also the likelihood of future conflicts arising. The Current Question 12. Hardly anyone will be inconvenienced if the existing library is renamed. The maintainer will need to do a small amo
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 fragment
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: 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#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: 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]
Re: TC voting and amendment procedure
Steve Langasek writes ("Re: TC voting and amendment procedure"):
> 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.
As I responded in my mail of Sun, 23 Sep 2007 16:23:54 +0100,
I think we would be better off doing what I've seen done in some
courts: we vote on the decision but each write our own rationale.
Otherwise we'll get bogged down in unnecessary arguments over the
rationale - and what if we can agree on the decision but there is no
rationale that will command a majority ?
And in fact getting bogged down in unnecessary arguments over the
rationale is _exactly_ what is happening here.
Everyone (even AJ, it seems) agrees that glibc in sid and lenny should
be changed immediately. The only thing we disagree about is the
whether that's because it's a release critical bug, or because we're
going to browbeat the IETF, or whatever, whether we should also
mandate the change in etch, and so on.
My extensive rationale, which amongst other things describes in detail
the reasoning behind my conclusion that rule 9 makes no sense for
IPv4, has been available for three weeks and no-one has (1) suggested
concrete changes to the wording or (2) formally proposed a resolution
including that rationale text or some other rationale text.
The whole point of ruling on the _conclusions_, that is the
_formal directions and recommendations_, without including detailed
reasoning in the resolution, is precisely to allow us to proceed to
make a decision despite the fact that our reasons will inevitably
differ from time to time.
> 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.
All you need to do is vote `yes' and add a line to your message saying
`I agree with this proposal for the reasons Ian sets out in his
rationale'.
This complaint that we should have further discussion would be more
convincing if there was actually further discussion going on.
I think that if you vote FD on a ballot then you are obliged to get
your hands dirty fixing whatever the problem was that caused you to
vote FD in the first place. In this case that means doing the
detailed work of drafting alternative ballot proposals, or at least
diffs to the current proposal.
> 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.
Our current rate of progress is approximately zero.
> 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.
I called for a vote because there had been no discussion on the matter
for a week. It's true that there was little time for discussion of my
detailed resolution text; since then I've been giving at least some
time for draft resolutions to be considered and alternatives suggested
before I call for a vote.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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]
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: 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
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: mixmaster /etc/default/*
On Sun, Dec 02, 2007 at 02:37:43AM -0800, Don Armstrong wrote: > > 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. Huh? Those are the tech-ctte's currently open bugs. There are more examples in the archived reports for the tech-ctte. The reason there's so few open atm is because we managed to do a purge recently, not because we've been good at dealing with issues. > > 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. I'm not particularly worried about the ctte going looking for problems; I'm worried about us effectively rewarding the act of escalating arguments over trivial matters, while ignoring and not dealing with important matters. There are a few problem areas in Debian where, IMO, the technical committee is the right group to be stepping in and finding a solution, but personally, I'm still a long way from seeing much evidence that we can collectively be trusted to actually achieve a good result. Go through the archived ctte bugs, eg. Here's my summary, divided into bugs that I think were handled well, ones that were handled ok eventually, after a long delay, and ones that I think are just kind of embarrassing. (Note that these are just the bugs still assigned to the tech-ctte, it doesn't include ones that got reassigned to other packages) Yay! 266762, 266837, 270506: assigned to ctte 20th Aug 2004 discussion up to 24th Aug 2004 resolves dispute 'til release is done experimental fix done after freeze on 4th May 2005 273760: assigned to ctte 28th Sep 2004 closed by non-ctte member with "This is a misplaced rant, not a bug report." on 29th Sep 2004 343472, 345067: assigned to ctte 7th Mar 2006 some comments and attempts at mediation issue resolved by maintainer to submitter's satisfaction by 14th Mar 2006 402772: assigned to ctte 12th Dec 2006 no resolution by the ctte, though some analysis and suggestions resolved by maintainer, security team and release team to mutual satisfaction on 16th Dec 2006 413926: assigned to ctte 6th Mar 2007 turned into a request for advice rather than dispute resolution on 25th Mar 2007 resolved on 27th Mar 2007 Yawn 316883, 329409, 341901, 342455: assigned to ctte 7th Dec 2005 resolution to overrule maintainer drafted on 3rd Apr 2006, resolved in favour on 9th Apr 2006 NMU performed implementing resolution dated 4th Jun 2006 accepted by maintainer 10th Jun 2006 353277, 353278: assigned to ctte 20th Feb 2006 resolution "should remain in main" passes 9th Apr 2007 367709: assigned to ctte 17th May 2006 closed with "no longer relevant" on 14th Jun 2007 reopened on 14th Jun 2007 vote called on 22nd Jun 2007 resolution that "a libstdc++ udeb should not be created" passes on 22nd Jun 2007 385665: assigned to ctte 20th Sep 2006 resolution "should remain in main" passes 9th Apr 2007 Boo :( -- 119517: assigned to ctte 14th Nov 2001 resolved on the 19th Jun 2002, as "we agree with the maintainer, the bug reports should be closed with no action", with four ctte members voting with a 2-all tie between the resolution and further discussion, resolved by the chair's casting vote 107150: assigned to ctte 1st Aug 2001 no resolution or consensus from the ctte resolved 19th Mar 2002 by maintainer changing his mind bug closed by non-ctte member 154950: assigned to ctte 31st Jul 2002 vote requested by submitter 14th Sep 2002 resolved by consensus of developers by 18th Sep 2002 resolution marking the issue resolved and noting that "The Committee regret that we have failed to get to grips with the actual dispute or issue in the question of bug #154950 and the Gnome transition." drafted on 23rd Oct 2002 report closed by submitter on 24th Oct 2002 341839: assigned to ctte 16th Dec 2005 resolution to ignore previous ctte decision passed 19th Jun 2007 350739: assigned to ctte 3rd Apr 2006 no action by tech ctte resolved 3rd Sep 2006 with upload of cdrkit 366938: assigned to ctte 12th May 2006 some discussion and draft resolutions proposed closed with "no longer relevant" on 14th Jun 2007 All but one of the bugs I think were successfully dealt with didn't require a vote, and the one that did was a request for advice rather than a dispute resolution
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]
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: 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: 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]
