Re: Thinking about Delegating Decisions about Policy
Hey Sam, Sorry it took us so long to get back to you on this. Sean and Ian already had quite some interesting discussion on this subject. And we also talked about this issue during our monthly meeting in June [1]. The rough consensus from our discussion is that the technical committee can always be consulted when policy editors don't see consensus among developers, but we feel it's the role of policy editors (and not the TC) to decide on what to do about policy, informed by what the whole project is doing. At least this advisory role is our understanding of how the Constitution defines the role of the TC. Of course, there is scope for doing more in the way of constructive consensus building, and you've been doing some great stuff in that direction. There doesn't seem to be anything that makes the TC in any way uniquely qualified for this work (possibly the reverse), so people that are good at that should just get on with it regardless of whether they are TC members, DPLs, or anyone else. There's been a lot of unhappiness sort-of-recently regarding the role of the TC. In particular, the fact that raising an issue to the TC causes a lot of friction and people need to almost be having a flame-war before coming to us. So, it might make sense to actually discuss the role of the TC and how this situation can be improved during the TC BOF at DebConf19 next week (Friday July 26th - 14:30 DebConf time). [1]: http://meetbot.debian.net/debian-ctte/2019/debian-ctte.2019-06-19-18.59.log.html -- Regards, Marga (with input from Phil and David)
Re: Thinking about Delegating Decisions about Policy
Thanks a lot Guillem for this message. It's very timely as we just had a discussion around these issues during DebConf19 in Curitiba, and many of the problems that we identified and discussed matched what your were saying. I think the TC needs to keep working on these issues and figure out how we want to move forward. Your input is super valuable for this. Thanks! -- Regards, Marga
Re: Date and Upsteam-URL fields
Hi! On 6/8/06, Kai Hendry <[EMAIL PROTECTED]> wrote: On 2006-06-08T17:49-0700 Chris Waters wrote: > Until dpkg supports it, there's little point in debating it on -policy. So that's how it works? First dpkg implements the feature, then we can think about making it policy? Actually, yes. That's how it works. Most things are declared "policy" when packages are already following it and it has been proved that it's a good idea to do it that way. If things were declared "policy" whenever the Policy Maintainers felt like it, almost all the packages could suddenly have a really big number of RC bugs, due to failure to previously knowing the new policy. The devel-reference hack isn't working. Try: egrep URL /var/lib/dpkg/available egrep -i Homepage /var/lib/dpkg/available egrep Website /var/lib/dpkg/available Do you really want me to file bugs? You can file bugs if you want, but just file them "wishlist", since the Dev-Ref is just a reference, not policy. Not following the Dev-Ref is not an important bug, and in this case, it's not even minor. We owe this to upstream too. I think upstream would love the link backs to their sites. Uhm, they might like it. But we don't "owe" them the links. The links should be present in the copyright file, the rest is just for our own use. So, in any case, I'd encourage you to patch dpkg to handle a new "Homepage" field, and submit the patch. Once this is being used by a big number of packages, you might bring this up again. I'd really like to have the Homepage field in dpkg, although I doubt it would enter policy. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372148: Bug confirmed
tags 372148 +confirmed patch
tnx
I've been looking at this bug in the documentation, and what Justin says is
completely true. I've found out that my diagrams also beared this bug
(maybe because I made them while reading the docs, or maybe because policy
was updated to reflect my diagrams :-\). I have updated the diagrams and
checked that all the info is correct now.
So, just to keep clear what needs to be changed, I've attached a patch to
the sgml document that fixes all the bugs reported.
(Also, it should be noted that 'an "Half-Installed" state' is incorrect and
should be replaced by 'a "Half-Installed" state', but I've left it out of
this patch to keep things clear).
--
Besitos, {o_
Marga. (')_
--- policy.sgml 2006-06-10 23:15:43.997173864 -0300
+++ policy-patched.sgml 2006-06-10 23:35:54.865522430 -0300
@@ -3469,7 +3469,7 @@
If that works, then
-new-postinst abort-upgrade new-version
+old-postinst abort-upgrade new-version
is called. If this works, then the old version
is in an "Installed" state, or else it is left
@@ -3601,7 +3601,7 @@
"Half Installed" state. If it works, dpkg now
calls:
-new-postinst abort-upgrade new-version
+old-postinst abort-upgrade new-version
If this fails, the old version is in an
"Unpacked" state.
@@ -3768,6 +3768,11 @@
postrm remove
+
+
+If it fails, there's no error unwind, and the package is in
+an "Half-Installed" state.
+
@@ -3782,19 +3787,6 @@
removed, as there is no difference except for the
dpkg status.
-
-
-If something fails, the following is done for error
-rewind:
-
-postinst abort-remove
-
-
-
-If the error unwind fails, the package is in an
-"Half-Installed" state, or else it remains "Installed"
-- even though all the files may have been deleted..
-
The conffiles and any backup files
@@ -3809,9 +3801,8 @@
-If this fails, the package remains in and "Installed'
-state -- even though by this point the files are all
-gone, and the conffiles may have been deleted.
+If this fails, the package remains in a "Config-Files"
+state.
signature.asc
Description: Digital signature
Bug#366466: Patch attached
tag 366466 +patch thanks The first of the two bugs reported had already been fixed in the arch-repo. The other one, hadn't been fixed, so I made a tiny patch. Also, the margins of that paragraph were indented one extra space, so I fixed that as well. -- Bessos, Maggie. --- upgrading-checklist.html2006-06-11 00:02:07.430635983 -0300 +++ upgrading-checklist-patched.html2006-06-11 00:08:19.774627838 -0300 @@ -84,9 +84,9 @@ elided). However, any parser for the control file must allow the Uploaders field to by spread over multiple physical lines as well, to prepare for future changes. [ 5.1, 5.6.3 ] - * When scripts are installed into into a directory in the system -PATH, the script name should not include an extension that -denotes the scripting language currently used to implement it. + * When scripts are installed into a directory in the system + PATH, the script name should not include an extension that + denotes the scripting language currently used to implement it. [ 10.4 ] * packages that invoke initscripts now must use invoke-rc.d to do so since it also pays attention to run levels and other local signature.asc Description: Digital signature
Bug#372522: Patch attached
tag 372522 +patch thanks This is a simple fix, but I took the time to search and couldn't find any other "double dot", so I decided to make a patch. -- Bezos, (o. Marga. (/)_ --- policy.sgml 2006-06-10 23:15:43.997173864 -0300 +++ policy-patched.sgml 2006-06-10 23:48:37.256557971 -0300 @@ -5142,7 +5142,7 @@ configuration files for applications are stored in the user's home directory are relaxed. It is recommended that such files start with the - '..' character (a "dot file"), and if an + '.' character (a "dot file"), and if an application needs to create more than one dot file then the preferred placement is in a subdirectory with a name starting with a '.' character, (a "dot signature.asc Description: Digital signature
Re: Bug#363486: dpkg: [update-alternatives] New categories for: WORD, EXCEL, MEDIA-PLAYER etc.
On 6/12/06, Jari Aalto <[EMAIL PROTECTED]> wrote: Is there any coordinated effort to standardize the name of the provided programs in /etc/alternatives? I don't think this concerns debian-policy at all. The use of alternatives is something that needs to be coordinated amont the maintainers of packages. It's not a question of policy or of dpkg. So, in order to have an alternative link for x-word-processor or x-spreadsheet, you need to file wishlist bugs against the packages that would be involved, and then have the maintainers agree with each other what to do. But, before doing so, it would be a good idea to discuss about this on debian-devel. I suggest you post the original proposal to debian-devel, explaining the full rationale on why you want this, what would need to be changed, what would be the benefits for the users and what would be the maintainers' resposibilities. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First draft of review of policy must usage
On 10/25/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote: I have replaced some uses of the word must when it was intended to be non-normative with alternate and equivalent wording, which makes it easier to grep for "must". This still needs to be done for should (which I often replace with 'ought to'). It would be nice to have a comment, footnote or similar thing that explains the differences between all these indicators: Something like this: * must / have to: you have to do this, no matter what. * should / ought to: it's a very good idea to do this, but in some special cases you might have a reason not to. I don't know if these are the meanings intended. All these verbs sound the same to me, but it seems they are intended to have different meanings, and I think it's better to make things as clear as possible. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
