Hi,
In the sprit of submitting bugs that affect a large number of
packages, this should be
a) discussed on the mailing list,
b) have bugs filed against all packages so that peole may edit the
control files.
I definitely think this should not be acted on out of hand.
I got a bug on frotz recently because it's in /usr/bin instead of
/usr/games. I think the present location is right, because frotz is a
virtual machine emulator, not a game itself. (OTOH, the programs which
run on it are mostly games.)
Rather than moving frotz to /usr/games, I could move the fro
Hi,
As I mentioned in a previsou message, I do not like this
trend. I understand people are annoyed at spurious bug reports, but
the goal is to have packages without bugs, and strictly prohibiting
automated bug reports is a Bad Thing.
Secondly, what purpose does asking each and
Hi,
I have a few comments on this.
2) Lintian bugs: Yes, the maintainer should make sure that the
package passes Lintian checks. If they do not, however, they
should expect to see bugs reported about that.
Lintian should not produce errors about things which are not
b
Galen Hazelwood <[EMAIL PROTECTED]> writes:
[ I've CC-ed this to debian-policy because I really do think we need
to start talking about a solution to the underlying problem here
rather than always working around it in half-assed ways. (I include
myself in that category). ]
> I don't believe any
On 18 Mar 1998, James Troup wrote:
> Ian Jackson <[EMAIL PROTECTED]> writes:
>
> > Noone may submit many bug reports or send mail to many maintainers
> > without prior approval for the specific person in question to send
> > mail under those specific circumstances.
>
> approval from whom?
S
Ian Jackson <[EMAIL PROTECTED]> writes:
> Noone may submit many bug reports or send mail to many maintainers
> without prior approval for the specific person in question to send
> mail under those specific circumstances.
approval from whom?
--
James
--
To UNSUBSCRIBE, email to [EMAIL PROTE
I think we should have the following much simpler and clearer policy:
Noone may submit many bug reports or send mail to many maintainers
without prior approval for the specific person in question to send
mail under those specific circumstances.
Even for violation by packages of an already-est
Santiago Vila <[EMAIL PROTECTED]> writes:
> Non maintainer releases do not close bugs. However, a non maintainer
> release that *just* fixes a bug because a bad building environment
> (buggy debstd, in this case) should probably be able to close such
> bugs. What do others think about this?
Just
-BEGIN PGP SIGNED MESSAGE-
[ moving to debian-policy ]
On Wed, 18 Mar 1998, Steve Greenland wrote:
> I'm going to downgrade the bug to normal, and ask that the
> package be put back into frozen. But not right now. Probably tomorrow
> night.
Well, you might probably better declare that
On Mon, Mar 16, 1998 at 03:38:12PM -0500, Igor Grobman wrote:
> > With the rash of self-appointed mass-posts of similar bugs (the most
> > recent being Michael Bramer's decision that all xpm files should be
> > moved), I think we need policy as to what can be done when someone trys to
> > formulate
> Maybe a dumb question, but what about bash's {,} syntax? If you have
> commands with commas in the names, it could make this somewhat
> awkward.
Yes, you're right. Then, we should remove , from the set of allowed
characters.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
On Tue, Mar 17, 1998 at 11:23:02PM -0500, Scott K. Ellis wrote:
> Having know immediate knowledge, I'll have to concede that it is possible
> that gcc isn't appropriate for all development (although what besides the
> kernel gcc can't handle hasn't become apparent to me).
As I understand it the c
On Tue, 17 Mar 1998, Dale Scheetz wrote:
> On Tue, 17 Mar 1998, Scott K. Ellis wrote:
>
> > On Tue, 17 Mar 1998, Dale Scheetz wrote:
> >
> > > Well, let me put it to you another way...Why is it libc6's responsibility
> > > to work out a problem between gcc and egcc. Libc6-dev depends on gcc and
On Tue, 17 Mar 1998, Scott K. Ellis wrote:
> On Tue, 17 Mar 1998, Dale Scheetz wrote:
>
> > Well, let me put it to you another way...Why is it libc6's responsibility
> > to work out a problem between gcc and egcc. Libc6-dev depends on gcc and
> > does not, at this time, depend on egcc.
>
> It p
15 matches
Mail list logo
