Bug#548867: developers-reference: Improve section about developer duties
Package: developers-reference Version: 3.4.3 Severity: normal Following a discussion on debian-newmaint, I think it's important to improve the section about the duties to clearly communicate to all package maintainers (and not DD only) that the bare minimum is what I described in the pledge below (it probably needs to reformulated in the third person for integration in the devel-ref): As a package maintainer, I will do my best to help the Debian project release a stable version of our operating system. In particular, I will work together with the release team and I will keep all packages associated to my name free of release critical bugs. To this effect, if I'm not registered as being busy or in vacation, I will start working on my release critical bugs as soon as possible (in less than 1 week in common cases). If I can't deal with them in a timely fashion, I will state it clearly in the associated bug reports, tag them help and invite other contributors either to provide a patch or to do a non-maintainer upload. If I do not manage to handle release critical bugs in the above described way, or if I almost never deal with any of my RC bugs by myself, I will: • not refuse help and even propose co-maintainance to good contributors • recognize my failure and actively try to find a new maintainer and/or co-maintainers • not complain if the quality assurance team decides to orphan the package I recognize that my work is not limited to unstable. I will also work with the stable release team and the security team to provide updated packages for the stable and/or testing distribution when some issues deserve it. I am aware of the limits of my skills and my available time and I will avoid packaging software that I would not be able to maintain properly. See discussion starting here: http://lists.debian.org/debian-newmaint/2009/09/msg00018.html And in particular the message of Christoph Berg (DAM): http://lists.debian.org/debian-newmaint/2009/09/msg00032.html Cheers, -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548823: devref: please point to text file to get #debian-private password
On Mon, 28 Sep 2009, Ryan Niebur wrote: instead of wasting peoples time, making them read through debian-private list archives, trying 3 wrong passwords until they finally discover that they could have figured it out much, much easier if devref had not mislead them. Sounds reasonable. I suggest providing a patch which makes this change. Don Armstrong -- We were at a chinese resturant. He was yelling at the waitress because there was a typo in his fortune cookie. -- hugh http://www.gapingvoid.com/Moveable_Type/archives/000321.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#548867: developers-reference: Improve section about developer duties
On Tue, Sep 29 2009, Raphaël Hertzog wrote: Following a discussion on debian-newmaint, I think it's important to improve the section about the duties to clearly communicate to all package maintainers (and not DD only) that the bare minimum is what I described in the pledge below (it probably needs to reformulated in the third person for integration in the devel-ref): Also, as mentioned in the discussion, the language should be made less patronizing and confrontational, and be a better fit for a standards document. --8---cut here---start-8--- Responsibilities of a Debian developer == = == = A Debian developer is responsible for properly maintaining their packages, and help maintain the quality of implementation for the OS as a whole, and to ensure that their packages integrate nicely with others and follow the Debian technical policy. Amongst other things, a Debian Developer has the responsibility to help in releasing a stable version the OS, which includes: - Work with the release team towards making the release happen - Keep the packages under their control free of release critical bugs, and work on RC bugs in a timely fashion - Release critical bugs should be considered to be amongst the highest priority tasks that the developer has in Debian - If timely response is not possible (due to time constraints, for example), this status should be mentioned clearly in the associated bug reports, and these reports should be tagged help. - RC bugs that are difficult to correct should be tagged help The developer also has the responsibility to work with the security and stable release teams and help provide updated packages for the stable and/or testing releases as needed. If the developer has time, and ability, they should also help their fellow developers deal with release critical bugs, by providing patches, and if necessary by doing NMU's (see NMU procedures elsewhere in this document) Release critical bugs need to ber fixed ASAP, and they are automatic invitations for bug fixing NMU's, and long standing RC bugs make the package unsuited for release, and lack of attention to RC bugs is grounds for the QA team to orphan the package. --8---cut here---end---8--- The other bits about recognizing their lack of ability and rubbing their faces in their own failure sound kind of pompous, and are unsuited for a high quality standards document, in my opinion. manoj -- Bond reflected that good Americans were fine people and that most of them seemed to come from Texas. -- Ian Fleming, Casino Royale Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#530687: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Mon, Sep 21 2009, Russ Allbery wrote: Giacomo A. Catenazzi c...@debian.org writes: ok. fair enough. BUT: the original proposal and this proposal contain only the duet: + A package may specify an architecture wildcard. Architecture + wildcards are in the format ttvaros/var/tt-any and + any-ttvarcpu/var/tt. footnoteInternally, the package The triplets are listed only in the footnote (which is IMHO confusing). But if we want to support the klibc (and in general different libc ABI), as it seems nice, this proposal should be more explicit about the use of triplet, allow them in the usual places, and policy should set the default value. Yes, I think I agree with all of that. Any suggestions on the wording? I was treating this proposal as merely reserving the namespace, and a later proposal coming forth with actual details of the usage, when multi-arch is further along. So, unless there are objections, I would like to see the wording changes go in now, with clarifications added as and when multi-atch solidifies. manoj -- Backed up the system lately? Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#391836: debian-policy: New virtual package: cron-daemon
On Fri, Sep 18 2009, Steve Langasek wrote:
Hmm. You do have a point. However, the original use case was
for a package to be able to have it's log files rotated periodically,
and by that criteria cron, anacron, fcron, and bcron do fit the bill.
I think perhaps we need to pare down the requirements (and
perhaps change the name of the virtual package), so that packages that
just want a periodic job scheduler don't have to specify a list of
matching providers.
Requirements:
1) Be able to run a batch job periodically.
2) Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
On Thu, Sep 17, 2009 at 09:03:22AM +, Gerrit Pape wrote:
On Wed, Sep 16, 2009 at 10:32:04PM -0700, Steve Langasek wrote:
fcron doesn't appear to run cron.daily by default, and neither does bcron.
*Only* the cron package ships a crontab that runs /etc/cron.daily by
default; anacron also supports running cron.daily, but relies on cron
itself
to trigger it on a daily basis. (Without cron installed, anacron will only
rotate logs when you reboot.)
Hi, the bcron-run package provides /etc/crontab, which includes
24 4 * * * root test -x /usr/sbin/anacron || run-parts --report
/etc/cron.daily
Ok, then the bcron-run package (but not the bcron package) would meet that
requirement.
So. We have a criteria that would allow for anyone needing to
set up a periodic cron job, and at least two packages that provide such
functionality: cron, and bcron-run.
Is this sufficient to add a virtual package?
manoj
--
The little pieces of my life I give to you, with love, to make a quilt
to keep away the cold.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
Hi, Given that there have been no objections or wording change suggestions, I would like to ask for seconds on this. manoj Support for architecture wildcards has been added to dpkg-1.13.13. This patch, based on a proposal from Andres Mejia, provides policy on how architecture wildcards should be used for other tools such as sbuild and pbuilder. This patch has tracked and incorporated suggestions embedded the discussion of the proposal. It also brings policy up to speed and in line with dpkg-dev which appears to generate an Architecture line that includes both architectures and special values like all. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530687 http://lists.debian.org/debian-policy/2009/05/msg00108.html for details. Signed-off-by: Andres Mejia mcita...@gmail.com Signed-off-by: Manoj Srivastava sriva...@debian.org --- policy.sgml | 80 +++--- 1 files changed, 70 insertions(+), 10 deletions(-) diff --git a/policy.sgml b/policy.sgml index 0bf1001..6624f33 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2726,7 +2726,12 @@ Package: libc6 values: list itemA unique single word identifying a Debian machine - architecture as described in ref id=arch-spec. +architecture as described in ref id=arch-spec. +/item +item + An architecture wildcard identifying a set of Debian + machine architectures, see ref id=arch-wildcard-spec. +/item itemttall/tt, which indicates an architecture-independent package. itemttany/tt, which indicates a package available @@ -2737,15 +2742,16 @@ Package: libc6 p In the main filedebian/control/file file in the source - package, this field may contain the special value - ttany/tt, the special value ttall/tt, or a list of - architectures separated by spaces. If ttany/tt or - ttall/tt appear, they must be the entire contents of the - field. Most packages will use either ttany/tt or - ttall/tt. Specifying a specific list of architectures is - for the minority of cases where a program is not portable or - is not useful on some architectures, and where possible the - program should be made portable instead. + package, this field may contain either the special value + ttany/tt, or the special value ttall/tt, or a list of + specific and wildcard architectures separated by + spaces. If the special ttany/tt appears, it must + be the entire contents of the field. Most packages will + use either ttany/tt or ttall/tt. Specifying a + specific list of architectures is for the minority of + cases where a program is not portable or is not useful on + some architectures, and where possible the program should + be made portable instead. /p p @@ -2786,6 +2792,22 @@ Package: libc6 package, ttall/tt will also be included in the list. /p + p + Specifying a list of architecture wildcards indicates that +the source will build an architecture-dependent package on +the union of the lists of architectures from the expansion +of each specified architecture wildcard, and will only +work correctly on the architectures in the union of the +lists.footnote As mentioned in the footnote for +specifying a list of architectures, this is for a minority +of cases where the program is not portable. Generally, it +should not be used for new packages. Also note that the +wildcards are not expanded then compared, they are simply +matched. /footnote If the source package also builds at +least one architecture-independent package, ttall/tt +will also be included in the list. + /p + p In a file.changes/file file, the ttArchitecture/tt field lists the architecture(s) of the package(s) @@ -4257,6 +4279,23 @@ Build-Depends: foo [!i386] | bar [!amd64] source package section of the control file (which is the first section). /p +p + All fields that specify build-time relationships + (ttBuild-Depends/tt, ttBuild-Depends-Indep/tt, + ttBuild-Conflicts/tt and ttBuild-Conflicts-Indep/tt) may also + be restricted to a certain set of architectures using architecture + wildcards. The syntax for declaring such restrictions is the same as + declaring restrictions using a certain set of architectures without + architecture wildcards. + For example: + example compact=compact
Re: Bug#491318: init scripts should support start/stop/restart/force-reload - why not must?
On Mon, Sep 14 2009, Henrique de Moraes Holschuh wrote: On Fri, 11 Sep 2009, Manoj Srivastava wrote: Looking at the bug report, it seems like we agree that the current policy is correct, and the should should not be changed to a must? In that case, can we just close this report? Alternatively, the proposal should be clarified to mention that it is optional for system startup scripts (runlevel S), but mandatory for everyone else. Daemon and regular service initscripts really ought to implement all actions, and do so *sensibly*. Would you care to suggest wording to the effect? manoj -- Penn's aunts made great apple pies at low prices. No one else in town could compete with the pie rates of Penn's aunts. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH] bug530687-srivasta: Support for architecture wildcards
On Tue, 2009-09-29 at 13:39 -0500, Manoj Srivastava wrote: Hi, Given that there have been no objections or wording change suggestions, I would like to ask for seconds on this. + like in: + example + gnu-linux-i386 == gnu-linux-any + gnu-kfreebsd-amd64 == any-any-amd64 + /example A possibly confusing use of '==' there - would it be better to say 'is matched by'? Other than that quibble, I'm happy to second this. Regards, Andrew McMillan. http://andrew.mcmillan.net.nz/ Porirua, New Zealand Twitter: _karora Phone: +64(272)DEBIAN Open Source: the difference between trust and antitrust signature.asc Description: This is a digitally signed message part
