Manoj Srivastava writes (Re: Bug mass filling):
On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson [EMAIL PROTECTED] said:
There are two different and orthogonal properties of a policy
requirement:
1. [...]
[and]
2. Is a violation of the requirement release-critical
On Thu, 26 Oct 2006 12:02:31 +0100, Ian Jackson [EMAIL PROTECTED] said:
Manoj Srivastava writes (Re: Bug mass filling):
On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson
[EMAIL PROTECTED] said:
There are two different and orthogonal properties of a policy
requirement:
1
On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote:
So certain bugs can be marked $STABLE-ignore to allow transient rc
issues to be ignored for a release and will become no-ops after release.
Are you suggesting that each package can have a related list of
non-transient bugs that should
* Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]:
If you are aware of issues that are violations of muSt
directives that are never going to be RC, there should be a bug
opened on policy with severity important for every one of them.
I hope to have time post-etch-release to do
Manoj Srivastava [EMAIL PROTECTED] wrote:
On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED] said:
Is the word generally here an error? I read this as implying the
normal meaning of should -- that not everything which violates a
should mandate is a bug.
I am of
Manoj Srivastava [EMAIL PROTECTED] wrote:
On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek [EMAIL PROTECTED] said:
Because your choice of mapping blurs the distinction between
one-time exceptions for RCness (e.g., due to GRs for DFSG issues),
vs. policy violations that the release team
* Frank Küster ([EMAIL PROTECTED]) [061025 09:49]:
Manoj Srivastava [EMAIL PROTECTED] wrote:
On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED]
said:
Is the word generally here an error? I read this as implying the
normal meaning of should -- that not everything
On Wed, Oct 25, 2006 at 01:48:02AM -0400, Kevin Mark wrote:
Are you suggesting that each package can have a related list of
non-transient bugs that should be marked (with a new tags called )
ignore-this-policy-violation where this can be attached to any package
related bug for any length of
On Wed, 25 Oct 2006 09:31:42 +0200, Andreas Barth [EMAIL PROTECTED] said:
* Manoj Srivastava ([EMAIL PROTECTED]) [061024 23:53]:
If you are aware of issues that are violations of muSt directives
that are never going to be RC, there should be a bug opened on
policy with severity important for
On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava [EMAIL PROTECTED] said:
[...]
and for policy:
These classifications are roughly equivalent to the bug severities
serious (for must or required directive violations), minor, normal or
important (for should or recommended directive
Manoj Srivastava writes (Re: Bug mass filling):
On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek [EMAIL PROTECTED] said:
When there are issues addressed in policy that are black-and-white
where all violations of the policy requirement are definitely bugs,
but not all such violations
On Tue, 24 Oct 2006 17:18:20 +0100, Ian Jackson [EMAIL PROTECTED] said:
Manoj Srivastava writes (Re: Bug mass filling):
On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek
[EMAIL PROTECTED] said:
When there are issues addressed in policy that are
black-and-white where all violations
On Tue, 24 Oct 2006 07:21:35 +0200, Andreas Barth [EMAIL PROTECTED] said:
* Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
Strawman. No one is proosing that; we already have a mechanism for
making serious bugs non-RC (etch-ignore tags).
Etch-ignore tags are usually used for issues
On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan [EMAIL PROTECTED] said:
On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava
[EMAIL PROTECTED] said: [...]
and for policy:
These classifications are roughly equivalent to the bug severities
serious (for must or required directive
On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
Well, I did say that it was a very rough draft. ;)
Second try:
... However, this is not a direct mapping, and the release
managers determine the severity of each violation.
Direct mapping of *WHAT*? are you
On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote:
* Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
Strawman. No one is proosing that; we already have a mechanism for
making serious bugs non-RC (etch-ignore tags).
Etch-ignore tags are usually used for issues where we
On Tue, 24 Oct 2006 16:04:54 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
Well, I did say that it was a very rough draft. ;)
Second try:
... However, this is not a direct mapping, and the release
managers determine
On Tue, 24 Oct 2006 16:18:11 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Tue, Oct 24, 2006 at 04:51:08PM -0500, Manoj Srivastava wrote:
* Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
Strawman. No one is proosing that; we already have a mechanism
for making serious bugs non-RC
On Tue, 24 Oct 2006 17:00:45 -0500, Manoj Srivastava [EMAIL PROTECTED] said:
On Tue, 24 Oct 2006 13:49:01 -0400, Hubert Chan [EMAIL PROTECTED]
said:
On Mon, 23 Oct 2006 13:46:23 -0500, Manoj Srivastava
[EMAIL PROTECTED] said: [...]
and for policy:
These classifications are roughly
On Tue, Oct 24, 2006 at 06:48:10PM -0500, Manoj Srivastava wrote:
If you are aware of issues that are violations of muSt directives
that are never going to be RC, there should be a bug opened on
policy with severity important for every one of them.
Why? If these issues are downgraded to
On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote:
Since we already feel that our RM's are overworked (hence
dunc-tank and payment schemes), I strongly suggest we not add to the
RM's burdens any more than we have to.
This is a laughable suggestion, given that the RMs'
On Tue, 24 Oct 2006 18:36:43 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Tue, Oct 24, 2006 at 04:36:52PM -0500, Manoj Srivastava wrote:
Since we already feel that our RM's are overworked (hence dunc-tank
and payment schemes), I strongly suggest we not add to the RM's
burdens any more
On Tue, 24 Oct 2006 17:15:55 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Tue, Oct 24, 2006 at 06:48:10PM -0500, Manoj Srivastava wrote:
If you are aware of issues that are violations of muSt
directives that are never going to be RC, there should be a bug
opened on policy with
On Tue, Oct 24, 2006 at 04:04:54PM -0700, Steve Langasek wrote:
On Tue, Oct 24, 2006 at 05:00:45PM -0500, Manoj Srivastava wrote:
Well, I did say that it was a very rough draft. ;)
Second try:
... However, this is not a direct mapping, and the release
managers determine the
On Sun, Oct 22, 2006 at 10:48:26PM -0700, Russ Allbery wrote:
I don't think using any non-POSIX feature should be a policy violation,
probably. There are some that are in such widespread use and are
supported by all shells that weren't written specifically as test suites
that I think it's
On Sun October 22 2006 23:22, Manoj Srivastava wrote:
I still think we should go for quality of implementation.
I also seem to be a minority in this regard.
I sincerely hope not.
If the project feels that we should downgrade policy not to
set our maintainer scripts
Gabor Gombas [EMAIL PROTECTED] writes:
How about instead of speaking about POSIX, policy should just list the
shells that are officially supported as /bin/sh? There is no need
listing every shell, just a representative subset: bash (obviously),
dash (it's popular) and an other minimalistic
On Sat, 21 Oct 2006 15:40:28 -0500, Manoj Srivastava [EMAIL PROTECTED] said:
Gee. Don't we already have something very like this?
These classifications are roughly equivalent to the bug
severities _serious_ (for _must_ or _required_ directive violations),
_minor_, _normal_ or
On Sun, 22 Oct 2006 22:48:26 -0700, Russ Allbery [EMAIL PROTECTED] said:
Manoj Srivastava [EMAIL PROTECTED] writes:
I personally think that maintainer scripts should allow for /bin/sh
to be not bash; or there should be documentation to the effect that
non bash /bin/sh is not supported.
On Mon, 23 Oct 2006 12:05:09 +0200, Gabor Gombas [EMAIL PROTECTED] said:
On Sun, Oct 22, 2006 at 10:48:26PM -0700, Russ Allbery wrote:
I don't think using any non-POSIX feature should be a policy
violation, probably. There are some that are in such widespread
use and are supported by all
On Mon, 23 Oct 2006 12:30:20 -0400, Hubert Chan [EMAIL PROTECTED] said:
On Sat, 21 Oct 2006 15:40:28 -0500, Manoj Srivastava
[EMAIL PROTECTED] said:
Gee. Don't we already have something very like this?
These classifications are roughly equivalent to the bug severities
_serious_ (for _must_
* Manoj Srivastava ([EMAIL PROTECTED]) [061023 20:14]:
Strawman. No one is proosing that; we already have a mechanism
for making serious bugs non-RC (etch-ignore tags).
Etch-ignore tags are usually used for issues where we expect them to be
RC after etch releases. If we think an issue
(Yes, I'm on vacation, and really am still on vacation, but I had a brief
check-in moment and happened to see this thread. Note that I probably
won't see responses, unless I get to them tomorrow night, until the
beginning of November.)
Aurelien Jarno [EMAIL PROTECTED] writes:
I have just run
On Sat, Oct 21, 2006 at 07:39:47PM -0500, Manoj Srivastava wrote:
Is a bashism in a /bin/sh script a normal bug (should only use
POSIX features), or a RC bug (the appropriate shell bust be
specified)? It's much easier to work out by just looking at the
rc_policy text file maintained by the
On Mon, 23 Oct 2006 12:24:29 +1000, Anthony Towns aj@azure.humbug.org.au
said:
On Sat, Oct 21, 2006 at 07:39:47PM -0500, Manoj Srivastava wrote:
Is a bashism in a /bin/sh script a normal bug (should only use
POSIX features), or a RC bug (the appropriate shell bust be
specified)? It's
Manoj Srivastava [EMAIL PROTECTED] writes:
I personally think that maintainer scripts should allow for
/bin/sh to be not bash; or there should be documentation to the
effect that non bash /bin/sh is not supported.
People actually use non-bash shells as /bin/sh and I get real bugs
Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
^^
*that* will be a great feature..:)
signature.asc
Description: Digital signature
On Sat, 21 Oct 2006, Christian Perrier wrote:
Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
^^
*that* will be a great feature..:)
This should in theory be working now.
Usertag:
* Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]:
On Sat, 21 Oct 2006, Christian Perrier wrote:
Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
^^
*that* will be a great
On Sat, 21 Oct 2006, Andreas Barth wrote:
* Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]:
On Sat, 21 Oct 2006, Christian Perrier wrote:
Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
Miriam Ruiz wrote:
Why don't we all try to calm down and get less paranoid?
I hope there are big Finnish saunas in Edinburgh.
I think we all need to gather for a hot sauna next DebConf.
We should change this you can't flame people you have had sauna with
to you can't flame me until you've had
Anthony Towns wrote:
Please hold off on filing them for a few days, so I can add
usertag-on-submit support to debbugs, so that it should be possible to
automatically track this stuff, and easily avoid filing duplicate bugs
if they're not fixed the next time bugs get filed.
Thanks, AJ. That is
[Don Armstrong]
Well, once I wake up a bit, you'll be able to go:
Package: foopkg
User: username
Usertags: fooblehtag,bartag
[But it won't work for setting multiple users... to do that, you'll
have to use control.]
This is even better. Is there a web page documenting this new
feature?
On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
That's not correct. [serious, grave, and critical] are the
release critical severities, though some release critical
issues won't be fixed for any
On Sat, 21 Oct 2006, Petter Reinholdtsen wrote:
[Don Armstrong]
Well, once I wake up a bit, you'll be able to go:
Package: foopkg
User: username
Usertags: fooblehtag,bartag
[But it won't work for setting multiple users... to do that, you'll
have to use control.]
This is even
On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote:
Gee. Don't we already have something very like this?
These classifications are roughly equivalent to the bug severities
_serious_ (for _must_ or _required_ directive violations), _minor_,
_normal_ or
On Sun, 22 Oct 2006 09:28:54 +1000, Anthony Towns aj@azure.humbug.org.au
said:
On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote:
Gee. Don't we already have something very like this?
These classifications are roughly equivalent to the bug severities
_serious_ (for _must_ or
On Thu, 19 Oct 2006 18:49:09 +0100, Adam D Barratt [EMAIL PROTECTED] said:
On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote:
Tshepang Lekhonkhobe wrote:
Doesn't policy violation warrant Critical severity?
No, it only warrants the lowest RC severity, serious [0], unless
the bug
Why don't we all try to calm down and get less paranoid?
I don't think anyone's trying to piss off anyone, so I think we should all try
to take it less personal. We probably all have different priorities, different
goals and different ideas on how to achieve them, and I don't think anyone's
On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote:
Even then, it's only serious if it violates the release policy
[http://release.debian.org/etch_rc_policy.txt]. Hence the reason
that
No. A bug may be serious and yet not RC, as I understand it.
That's not correct.
On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:
Maybe some errors (E:) of lintian could be changed to critical (C:) and
uploads containing such critical errors be refused by dak? What do you
think?
AFAIK dak doesn't support this? Does C: exist?
Among all of the bugs reported
Anthony Towns a écrit :
On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:
Maybe some errors (E:) of lintian could be changed to critical (C:) and
uploads containing such critical errors be refused by dak? What do you
think?
AFAIK dak doesn't support this? Does C: exist?
No
* Aurelien Jarno ([EMAIL PROTECTED]) [061021 00:37]:
Anthony Towns a écrit :
On Thu, Oct 19, 2006 at 03:06:04PM +0200, Aurelien Jarno wrote:
Maybe some errors (E:) of lintian could be changed to critical (C:) and
uploads containing such critical errors be refused by dak? What do you
think?
On Sat, 21 Oct 2006 06:27:24 +1000, Anthony Towns aj@azure.humbug.org.au
said:
On Fri, Oct 20, 2006 at 04:06:05AM -0500, Manoj Srivastava wrote:
Even then, it's only serious if it violates the release policy
[http://release.debian.org/etch_rc_policy.txt]. Hence the reason
that
No. A bug
On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
That's not correct. [serious, grave, and critical] are the release
critical severities, though some release critical issues won't be
fixed for any given release, due to either being not known about or
understood (ie, not
On Fri, Oct 20, 2006 at 05:18:41PM -0700, Steve Langasek wrote:
On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
That's not correct. [serious, grave, and critical] are the release
critical severities, though some release critical issues won't be
fixed for any given
Hi all,
I have just run lintian on all the archive (amd64) for both binaries and
sources, and the results are a bit scary. It looks like a lot of
maintainers are uploading their packages, and don't really care with the
policy.
Maybe some errors (E:) of lintian could be changed to critical (C:)
[Aurelien Jarno]
I have just run lintian on all the archive (amd64) for both binaries and
sources, and the results are a bit scary. It looks like a lot of
maintainers are uploading their packages, and don't really care with the
policy.
What is the technical problem triggered by the
On 10/19/06, Petter Reinholdtsen [EMAIL PROTECTED] wrote:
[Aurelien Jarno]
I have just run lintian on all the archive (amd64) for both binaries and
sources, and the results are a bit scary. It looks like a lot of
maintainers are uploading their packages, and don't really care with the
[Tshepang Lekhonkhobe]
Doesn't policy violation warrant Critical severity?
Well, policy isn't a stick to beat other maintainers with, it is a
tool to make sure our packages are well integrated and work properly.
Thus, policy issues are not problems by themselves, they are policy
issues because
Tshepang Lekhonkhobe wrote:
Doesn't policy violation warrant Critical severity?
No, it only warrants the lowest RC severity, serious [0], unless the
bug in addition makes the package or other software (mostly) unusable,
causes data loss, or introduces a security hole.
[0]
On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote:
If no problem is caused by it, I believe 'normal' or even 'wishlist'
severity is the proper severity to use.
s/wishlist/minor/
It _is_ a bug after all.
pgp8CuxfBlHbn.pgp
Description: PGP signature
On Thu, Oct 19, 2006 at 06:45:53PM +0200, Petter Reinholdtsen wrote:
Well, policy isn't a stick to beat other maintainers with, it is a
tool to make sure our packages are well integrated and work properly.
Thus, policy issues are not problems by themselves, they are policy
issues because they
* Tshepang Lekhonkhobe ([EMAIL PROTECTED]) [061019 18:09]:
On 10/19/06, Petter Reinholdtsen [EMAIL PROTECTED] wrote:
[Aurelien Jarno]
I have just run lintian on all the archive (amd64) for both binaries and
sources, and the results are a bit scary. It looks like a lot of
maintainers are
* Aurelien Jarno ([EMAIL PROTECTED]) [061019 15:06]:
Among all of the bugs reported by lintian, one concerns a lot of
packages, the presence of the clean, binary, binary-arch, binary-indep
and build targets. This is required by both the section 4.9 of the
policy and the Etch release standards
On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
Doesn't policy violation warrant Critical severity?
No. Please see the top of http://release.debian.org/etch_rc_policy.txt
for which bugs are critical, grave and serious.
That is irrelevant for the severity of
On Thu, Oct 19, 2006 at 07:01:20PM +0200, Frans Pop wrote:
On Thursday 19 October 2006 18:45, Petter Reinholdtsen wrote:
If no problem is caused by it, I believe 'normal' or even 'wishlist'
severity is the proper severity to use.
s/wishlist/minor/
It _is_ a bug after all.
On Thu, 2006-10-19 at 19:51 +0200, Mike Hommey wrote:
On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
Doesn't policy violation warrant Critical severity?
No. Please see the top of http://release.debian.org/etch_rc_policy.txt
for which bugs are
On Thu, 2006-10-19 at 10:00 -0700, Kevin B. McCarty wrote:
Tshepang Lekhonkhobe wrote:
Doesn't policy violation warrant Critical severity?
No, it only warrants the lowest RC severity, serious [0], unless the
bug in addition makes the package or other software (mostly) unusable,
causes
On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote:
On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
Doesn't policy violation warrant Critical severity?
No. Please see the top of http://release.debian.org/etch_rc_policy.txt
for which bugs are
On Thu, Oct 19, 2006 at 11:29:38AM -0700, Steve Langasek [EMAIL PROTECTED]
wrote:
On Thu, Oct 19, 2006 at 07:51:19PM +0200, Mike Hommey wrote:
On Thu, Oct 19, 2006 at 07:36:27PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
Doesn't policy violation warrant Critical severity?
No.
* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
Note how subtly the Etch RC policy removes the first alternative of the
serious bug description...
Which do you mean? Please read the Etch RC policy. It tells:
| In addition to the issues listed in this document, an issue is release
| critical
On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
Note how subtly the Etch RC policy removes the first alternative of the
serious bug description...
Which do you mean? Please read the Etch RC policy. It
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
Note how subtly the Etch RC policy removes the first alternative of the
serious bug description...
On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
Note how subtly the
Andreas Barth a écrit :
A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
should be the same as the must-directives in policy, but - well, I hope
that I have finally time post-etch to sync that finally).
Any other
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:25]:
On Thu, Oct 19, 2006 at 09:17:38PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL
PROTECTED] wrote:
* Mike Hommey
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 20:42]:
Note how subtly the Etch RC policy removes the first
* Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]:
Andreas Barth a écrit :
A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
should be the same as the must-directives in policy, but - well, I hope
that I have
On Thu, Oct 19, 2006 at 09:35:38PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
But I need to admit that I get sick, seriously sick. If someone doesn't
agree with something, he just says you do it wrong just for release of
etch on $date. I really hate that. Especially when it's about things
On Thu, Oct 19, 2006 at 03:53:56PM -0400, Eric Dorland [EMAIL PROTECTED]
wrote:
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 21:14]:
On Thu, Oct 19, 2006 at 09:06:42PM +0200, Andreas Barth [EMAIL
PROTECTED] wrote:
* Mike Hommey ([EMAIL
On Thu, Oct 19, 2006 at 09:56:37PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Aurelien Jarno ([EMAIL PROTECTED]) [061019 21:31]:
Andreas Barth a écrit :
A violation of the parts of the debian policy as listed on
http://release.debian.org/etch_rc_policy.txt is serious level (that
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]:
That was not a link before it was changed before sarge release, in July
2004.
The link was added later because people were barking around. The meaning
was always the same.
Anyways, July 2004 is a *bit* history now, don't you think so?
So,
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
Where does it say the scope for 4. Autobuilding is buildds must not
fail ?
There are always bugs in any document.
For sarge, we e.g. sarge-ignored some MTAs which didn't provide -bs,
though LSB requires that. Now, we adjusted the policy to make
On Thu, Oct 19, 2006 at 10:15:16PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:06]:
That was not a link before it was changed before sarge release, in July
2004.
The link was added later because people were barking around. The meaning
was
On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
Where does it say the scope for 4. Autobuilding is buildds must not
fail ?
There are always bugs in any document.
Be aware that, even if you don't like it,
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
[another agression]
Sorry, but enough is enough. I'm fed up about your sudden agressions
towards me for no reason at all. Welcome to my killfile.
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Mike Hommey [EMAIL PROTECTED] wrote:
On Thu, Oct 19, 2006 at 10:20:46PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:09]:
Where does it say the scope for 4. Autobuilding is buildds must not
fail ?
There are always bugs in any document.
Be
Mike Hommey [EMAIL PROTECTED] writes:
So, what does the Etch RC policy remove from the bugs.d.o description?
'is a severe violation of Debian policy (roughly, it violates a must or
required directive), or'
Perhaps you should concentrate on the word roughly there. What
constitutes a severe
Mike Hommey [EMAIL PROTECTED] wrote:
Be aware that, even if you don't like it, this looks like you bend the
rules so that it doesn't alter the release plan.
Be also aware that too much bending the rules makes them useless.
Don't try to bend the rules, it's impossible. Instead, only realize
On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
[another agression]
Waw, actually, i was trying to be less aggressive...
Anyways, since I'm too pissed and since I see no reason to put myself in
that mood any
On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
[another agression]
Sorry, but enough is enough. I'm fed up about your sudden agressions
towards me for no reason at all. Welcome to my killfile.
Hi Andi,
from my
On Thu, Oct 19, 2006 at 10:52:25PM +0200, Mike Hommey wrote:
On Thu, Oct 19, 2006 at 10:37:38PM +0200, Andreas Barth [EMAIL PROTECTED]
wrote:
* Mike Hommey ([EMAIL PROTECTED]) [061019 22:29]:
[another agression]
Waw, actually, i was trying to be less aggressive...
This is a very, very
On Thu, 19 Oct 2006, Kevin Mark wrote:
DD's trying to use Debian policy as a guide to make all packages
pass policy requirement. Is this not what they are tasked to do?
There's nothing wrong with these goals. Indeed, I'm sure no one would
object to patches and bugs being filed to fix these
On 10/19/06, Mike Hommey [EMAIL PROTECTED] wrote:
Waw, actually, i was trying to be less aggressive...
Anyways, since I'm too pissed and since I see no reason to put myself in
that mood any further, I'm taking a few days off Debian, which means my
current work on seamonkey^Hiceape will be on
95 matches
Mail list logo
