Previously Vincent Renardias wrote:
> Maybe not fixed, but if sent to the upstream developer, they should be
> marked as 'forwarded'. ;)
I like to get an acknowledgement from upstream before I mark a bug
as forwarded.. and I'm not getting that.
On of these days I'll fork strace :(
Wichert.
--
On Thu, 28 Jan 1999, Wichert Akkerman wrote:
> Previously John Goerzen wrote:
> > 1. There should be policy against ignoring bugs for an excessive amount of
> > time without good reason (eg, vacation)
>
> This is silly: for example I have a couple of ancient open bugs for
> strace for which I do
On 28-Jan-99 Hartmut Koptein wrote:
>> Why? Why should he be forced to acknowledge your bug reports? If you want
>> an
>> answer, pester him with email, yourself. Don't seek to get him thrown out
>> of
>> the Project.
>
> That was the reason one said "he should mail an notice about the bug rep
Previously John Goerzen wrote:
> 1. There should be policy against ignoring bugs for an excessive amount of
> time without good reason (eg, vacation)
This is silly: for example I have a couple of ancient open bugs for
strace for which I don't really have a clue how to solve them and an
upstream ma
> > 12 months ? If i send an bug-report i expect an answer within 1-2 weeks!!
> > Ok, for
> > some packages (like dpkg) i wait longer.
> >
> > So, if a maintainer doesn't answer within _one_ month he should be mailed!!!
> > After
> > a second month he should be set to 'hold'.
> Why? Why should
>From the constitution:
|8. The Project Leader's Delegates
|
|8.1. Powers
|
|The Project Leader's Delegates:
|
|1.have powers delegated to them by the Project Leader;
|2.may make certain decisions which the Leader may not make directly,
|including approving or expelling Developers or des
On 28-Jan-99 Hartmut Koptein wrote:
> 12 months ? If i send an bug-report i expect an answer within 1-2 weeks!!
> Ok, for
> some packages (like dpkg) i wait longer.
>
> So, if a maintainer doesn't answer within _one_ month he should be mailed!!!
> After
> a second month he should be set to 'hol
> > 12 months ? If i send an bug-report i expect an answer within 1-2 weeks!!
> > Ok, for
> > some packages (like dpkg) i wait longer.
> >
> > So, if a maintainer doesn't answer within _one_ month he should be
> > mailed!!! After
> > a second month he should be set to 'hold'.
>
> That's too
Hartmut Koptein wrote:
> 12 months ? If i send an bug-report i expect an answer within 1-2 weeks!!
> Ok, for
> some packages (like dpkg) i wait longer.
>
> So, if a maintainer doesn't answer within _one_ month he should be mailed!!!
> After
> a second month he should be set to 'hold'.
That's
> I would, too, for one thing. If a maintainer has been inactive (no email to
> lists, no packages uploaded) for a year (12 months). Email should be sent to
12 months ? If i send an bug-report i expect an answer within 1-2 weeks!! Ok,
for
some packages (like dpkg) i wait longer.
So, if a mai
On Thu, Jan 28, 1999 at 11:13:43AM -0800, Darren Benham wrote:
> > 2. Having that, there should be policy allowing the dismissal of people that
> > gratitiously violate policy.
>
> It's implicit. Do we need to make it explicit? What is "gratitiously"?
> Who'll make the accusation? Where will
On 28-Jan-99 John Goerzen wrote:
> I think that sounds reasonable, but I would like to see more concrete
> guidelines someplace, even if the authority remains with them (which is fine
> with me)
I would, too, for one thing. If a maintainer has been inactive (no email to
lists, no packages upload
On 28-Jan-99 John Goerzen wrote:
> 1. There should be policy against ignoring bugs for an excessive amount of
> time without good reason (eg, vacation)
No. I don't think so. 1) There's no good reason. 2) there's no good
definition to "excessive". 3) It can be handled by severity. (If you don
On Thu, Jan 28, 1999 at 09:29:41AM -0800, Darren Benham wrote:
> Project Leader Delegates (currently the New-Maintainers) have the "authority"
> to remove people from the project. It's up to their sole discression what is
> considered removable. Of course, if they "abuse" that authority, the
> r
On Thu, Jan 28, 1999 at 09:33:19AM -0800, Darren Benham wrote:
> If the maintainer is still around -- if he's posting on the list or uploading
> that or other packages -- he's still here. There's nothing in policy against
> ignoring bugs.
There are two issues here.
1. There should be policy a
If the maintainer is still around -- if he's posting on the list or uploading
that or other packages -- he's still here. There's nothing in policy against
ignoring bugs.
On 28-Jan-99 John Goerzen wrote:
> Again, as I said in my message, I'm not proposing removing developers that
> maintain pack
Project Leader Delegates (currently the New-Maintainers) have the "authority"
to remove people from the project. It's up to their sole discression what is
considered removable. Of course, if they "abuse" that authority, the
rest of the project would be quick to complain. General resolution can o
On Thu, Jan 28, 1999 at 05:30:03PM +0100, Raphael Hertzog wrote:
> Le Thu, Jan 28, 1999 at 09:13:04AM -0600, John Goerzen écrivait:
> > Again, as I said in my message, I'm not proposing removing developers that
> > maintain packages with bugs, or packages with very old bugs. This case is
> > diff
Le Thu, Jan 28, 1999 at 09:13:04AM -0600, John Goerzen écrivait:
> Again, as I said in my message, I'm not proposing removing developers that
> maintain packages with bugs, or packages with very old bugs. This case is
> different. The developer has literally *ignored* bugs for over 700 or 800
> d
On Thu, Jan 28, 1999 at 05:25:22PM +0100, Hartmut Koptein wrote:
> > In light if this, I ask if we have some mechanism for either removing a
>
> Not removing ... could we set these developers to an status 'hold' or a
> similary
> one?
When do we finally remove someone? When they haven't logge
> I view both of these as developers failing to live up to the responsibility
> that they accepted when they accepted maintainorship of packages. The
> second example is particularly bad; the developer could at least reply to
> the person submitting a bug.
>
> In light if this, I ask if we have s
On Thu, Jan 28, 1999 at 02:17:42PM +0100, Raphael Hertzog wrote:
> I really don't like your idea. There are many packages with many bugs :
> http://master.debian.org/~vincent/report-bybugnum.txt
> And also many packages with very old bugs :
> http://master.debian.org/~vincent/report-byage.txt
Aga
Le Wed, Jan 27, 1999 at 11:34:42PM -0600, John Goerzen écrivait:
> I am not proposing throwing people out for having bugs in their packages, or
> even for having lots of them. Rather, what I am proposing is a way to
> prevent people that ignore their responsibility from becoming a hindrance to
> t
John Goerzen wrote:
> In light if this, I ask if we have some mechanism for either removing a
> developer from Debian if they have serious lack of responsibility issues, or
> at least of declaring their packages orphaned and up for adoption. If not,
> I would like to ask that we consider drafting
Hi,
If there are others that want to take over the package, a lack
of response (after a reasonable period of time [reasonable is
measured in months, rather than hours]) can be taken to be assent.
Failing that, the new maintainer people have been given the
power to remove deve
Hi,
>>"Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes:
Joseph> On Wed, Jan 27, 1999 at 05:53:58PM -0600, Manoj Srivastava wrote:
>> I must confess that even I thought the the policy statement meant
>> that one should be able to install all optional packages
>> simultaneously.
Joseph> Th
Hello,
Recently there have been several things occuring that have prompted me to
start asking about this:
* Despite having Important, Critical, or Grave bugs filed against their
packages in frozen, some developers still ignore them. They could
at least say "I can't fix this; can somebody
On Wed, Jan 27, 1999 at 05:53:58PM -0600, Manoj Srivastava wrote:
> I must confess that even I thought the the policy statement
> meant that one should be able to install all optional packages
> simultaneously.
>
> Though this is a laudable goal, and indeed, was once
> achievable,
On Wed, Jan 27, 1999 at 10:35:54PM +0100, Remco Blaakmeer wrote:
> > This is not quite the case. FHS 2.0, like previous versions, aims for
> > somewhere between best practice and the common (Linux) practice.
> > Mostly Linux, actually, because Linux generally has a much cleaner
> > filesystem hier
Package: debian-policy
Version: 2.5.0.0
Section 4.4 of the packaging manual refers to "Csh Programming
Considered Harmful" in /pub/usenet-by-group/comp.unix.programmer on
rtfm.mit.edu. This file is not now in that directory.
This reference should be deleted, or the URL updated.
-- Sy
Santiago Vila wrote:
> Question: Since extra is for packages that conflict with others with
> higher priorities, and A and B are conflicting optional packages, does not
> effectively downgrading A (or B) to extra make it to conform to the
> definition of "extra"? (since optional > extra).
This wor
31 matches
Mail list logo
