2008/2/23, Stephen J. Turnbull <[EMAIL PROTECTED]>:
> If that curve ever turns down, it means that users are giving up on
> Python as a tool for solving ever harder problems. That's where it
> gets scarey.
It depends. If that happens because no new issues are found, maybe (it
could happen als
Facundo Batista writes:
> 2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>:
> > The flow seems healthy to me.
+1
> What I don't see healthy is that we have, per week, around 30 issues
> more open (30 is the difference between those closed, and the new
> ones).
>
> So, the curve is always go
2008/2/23, Steve Holden <[EMAIL PROTECTED]>:
> A larger team (not necessarily all committers) could help us improve
> quality and reduce the issue count. Deleting issues purely on grounds of
Exactly, that's why I love Python bug days.. and I'm pushing this hard
in Argentina!
In the January one
Facundo Batista wrote:
> 2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>:
>
>> The flow seems healthy to me.
>>
>
> What I don't see healthy is that we have, per week, around 30 issues
> more open (30 is the difference between those closed, and the new
> ones).
>
> So, the curve is always going up
2008/2/23, Virgil Dupras <[EMAIL PROTECTED]>:
>
> The flow seems healthy to me.
>
What I don't see healthy is that we have, per week, around 30 issues
more open (30 is the difference between those closed, and the new
ones).
So, the curve is always going up... fast.
--
.Facundo
Blog: http
On 2/23/08, Christian Heimes <[EMAIL PROTECTED]> wrote:
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.
There is also 12000 closed tickets, with 1200 of them having been
closed in the last
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.
As a historical record: people said the same thing when there were 500
and 1000 open issues. 5 years from now, when we have 5000 open issues,
On Sat, Feb 23, 2008 at 01:55:06AM +0100, Christian Heimes wrote:
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.
Sure, but is that because the bug life cycle is sub-optimal, or
because we d
On Fri, Feb 22, 2008 at 4:55 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> We have over 1,700 open issues - bug reports, feature requests and
> patches - in our bug tracker. In my humble opinion it's a sure sign for
> a problem.
I don't think so. I think it's a sign of healthy software. Now, i
A.M. Kuchling wrote:
> Are we, as a development community, really running into problems with
> how we handle bugs? There are certainly small cleanups possible, such
> as dropping the 'postponed' and 'later' resolutions that we don't seem
> to use very much, but the flow seems reasonably efficient
"Martin v. Löwis" writes:
> That's why the entire field is called "Resolution". "duplicate",
> "invalid", "out of date", "wont fix" and "works for me" are also
> firm decisions.
>
> ("later", "postponed", and "remind" might not be firm decisions -
> they were just inherited from SF).
These
On Fri, Feb 22, 2008 at 1:28 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:
> > I think Martin is right that someone needs to take the lead and do a
> > complete review of how issues are handled. That way we can do a change
> > in one
On Fri, Feb 22, 2008 at 1:21 PM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/2/22, Brett Cannon <[EMAIL PROTECTED]>:
>
>
> > I think Martin is right that someone needs to take the lead and do a
> > complete review of how issues are handled. That way we can do a change
> > in one big batc
On Fri, Feb 22, 2008 at 01:06:05PM -0800, Brett Cannon wrote:
> I think Martin is right that someone needs to take the lead and do a
> complete review of how issues are handled. That way we can do a change
> in one big batch to something that works better for Python.
Are we, as a development commu
2008/2/22, Brett Cannon <[EMAIL PROTECTED]>:
> I think Martin is right that someone needs to take the lead and do a
> complete review of how issues are handled. That way we can do a change
> in one big batch to something that works better for Python.
+1
What about a couple of hours in the Pyth
On Fri, Feb 22, 2008 at 10:01 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Can we make the names a little longer?
>
> Somebody really needs to take lead here. I won't change
> anything unless somebody tells me precisely what to do,
> so I can blame somebody. Messages like this (which I
>
> First two definitions of "resolve" from the American Heritage dict:
>
> 1. To make a firm decision about.
> 2. To cause (a person) to reach a decision.
>
> I think it applies quite well.
That's why the entire field is called "Resolution". "duplicate",
"invalid", "out of date", "wont fix" a
> Can we make the names a little longer?
Somebody really needs to take lead here. I won't change
anything unless somebody tells me precisely what to do,
so I can blame somebody. Messages like this (which I
picked just arbitrarily) I will ignore wrt. specific
action. Of course I *can* make the name
> We can go one step further: If we change "fixed" and "accepted" as
> "resolved" (for example), we can change all the values directly in the
> database, so they all appear as "resolved" now.
>
> I don't want to propose anything specific regarding words, I'm just
> saying that having eleven option
On Fri, Feb 22, 2008 at 4:57 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
># Feature request resolutions
>accepted - feature request accepted (possibly via attached patch)
>rejected - feature request rejected
Can we make the names a little longer? "feature accepted" and
"feature reject
Nick Coghlan schrieb:
> Facundo Batista wrote:
>> First two definitions of "resolve" from the American Heritage dict:
>>
>> 1. To make a firm decision about.
>> 2. To cause (a person) to reach a decision.
>>
>> I think it applies quite well.
>
> It only tells you that a resolution was reache
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>:
> Now, dropping 'later', 'postponed' and 'remind' from the list of
> available resolutions is something I could wholeheartedly support. If we
> want to postpone something to a later release, we should put an
> appropriate entry in the version list.
Facundo Batista wrote:
> First two definitions of "resolve" from the American Heritage dict:
>
> 1. To make a firm decision about.
> 2. To cause (a person) to reach a decision.
>
> I think it applies quite well.
It only tells you that a resolution was reached, not what that
resolution was.
2008/2/22, Nick Coghlan <[EMAIL PROTECTED]>:
> Combining 'fixed' and 'accepted' into something generic like 'resolved'
> is no good, since 'not a bug' is also a resolution from our point of
> view, even if the original author of the issue may not particularly like
> the answer :)
First two de
2008/2/21, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> It's possible to "retire" objects in Roundup: certain resolution values
> would still be present and referenced by issues that use it, but they
> would not appear anymore in the drop-down list.
We can go one step further: If we change "fixed"
2008/2/21, Brett Cannon <[EMAIL PROTECTED]>:
> Something like "handle" or "resolved". An issue is an issue and we
> wanting a single way to say the issue was closed because what is was
> about was handled seems reasonable.
+1 to resolved.
--
.Facundo
Blog: http://www.taniquetil.com.ar/pl
Gregory P. Smith wrote:
> I'm always faced with a tiny quandry when closing a fixed bug that had a
> patch to fix it attached because both seem to apply. ;-)
I try to use 'fixed' for those, with my closure comment indicating
whether the fix used the attached patch (or a variant thereof) or
som
On Thu, Feb 21, 2008 at 8:06 AM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/2/21, Gregory P. Smith <[EMAIL PROTECTED]>:
>
>
> > > That sounds eminently sensible. So sensible there should be
> > > documentation that tells us to do that. Drat it, where's Brett Cannon
> > > when you need him
On Thu, Feb 21, 2008 at 7:50 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]> wrote:
> >> On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> > - no selection -118
> >> > wont fix
> This is the result for the "open" status issues? I guess not, because
> the rejected, fixed, etc, should be closed.
>
> Could you run this again, please, but filtering by "open" tickets?
Here you go
- no selection -381
wont fix2
works for me0
accepted4
fixed 2
dup
> Everything in this aspect would be simpler if we have one word for
> what I just meant.
If you think it should be fixed, please submit a report in the meta
tracker, ideally specifying precisely how you want to see it changed.
It's possible to "retire" objects in Roundup: certain resolution valu
> What would be the difference between accepted and fixed for a closed ticket?
As Guido says: a bug gets fixed, a patch gets accepted. This was copied
over from SF, but it makes sense to me and everybody seems to be
following it.
Regards,
Martin
___
P
2008/2/21, Gregory P. Smith <[EMAIL PROTECTED]>:
> > That sounds eminently sensible. So sensible there should be
> > documentation that tells us to do that. Drat it, where's Brett Cannon
> > when you need him? :-)
>
> I'm always faced with a tiny quandry when closing a fixed bug that had a
> patch
On 2/21/08, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]>
> wrote:
>
> >> What would be the difference between accepted and fixed for a closed
> ticket?
> >
> > I don't know what others do, but I use acce
2008/2/21, Virgil Dupras <[EMAIL PROTECTED]>:
> I don't see why would want to run this query on open tickets. What
> would it tell you? How many old issue there is? You can already know
> that with a simple search. The goal of this script is to know the
> resolution of tickets that had a 6+ mon
On 2/21/08, Facundo Batista <[EMAIL PROTECTED]> wrote:
> This is the result for the "open" status issues? I guess not, because
> the rejected, fixed, etc, should be closed.
>
> Could you run this again, please, but filtering by "open" tickets?
I don't see why would want to run this query on open
Guido van Rossum wrote:
> On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]> wrote:
>> On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> > - no selection -118
>> > wont fix189
>> > works for me62
>> > accepted310
>> > fixed 611
>>
2008/2/20, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> - no selection -118
> wont fix189
> works for me62
> accepted310
> fixed 611
> duplicate 75
> later 17
> invalid 73
> postponed 6
> out of date 193
> remind 1
> rejected180
Thi
On Thu, Feb 21, 2008 at 08:59:51AM +0100, Virgil Dupras wrote:
> Thanks for running it. The rate is better than I expected, so I was
> wrong in my assumption.
>
> What would be the difference between accepted and fixed for a closed ticket?
'accepted' is probably used more for patches, while 'fixe
On Wed, Feb 20, 2008 at 11:59 PM, Virgil Dupras <[EMAIL PROTECTED]> wrote:
> On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > - no selection -118
> > wont fix189
> > works for me62
> > accepted310
> > fixed 611
> > duplicate 75
> > later
On 2/21/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> - no selection -118
> wont fix189
> works for me62
> accepted310
> fixed 611
> duplicate 75
> later 17
> invalid 73
> postponed 6
> out of date 193
> remind 1
> rejected18
Virgil Dupras wrote:
On 2/19/08, Virgil Dupras <[EMAIL PROTECTED]> wrote:
closed_status = db.status.lookup('chatting')
Oops, replace 'chatting' with 'closed'
Ok, I ran the script. It said
Low activity tickets (180 days) broken down per resolution status:
- no selection -547
wont fi
Martin v. Löwis wrote:
>> It must have changed since I last looked at a feature request on the
>> tracker - using a type rather than keyword is fine by me.
>
> I'm fairly certain the rfe type was there ever since the switchover
> (at least that's what subversion says: the rfe type was added along
I consider a feature request something like asking a factorial method (
http://bugs.python.org/issue2138). As for the RFE, (from Wikipedia) "while
not technically a bug, it is often tracked in the same manner as a bug as it
represents a failure to meet expected behavior, or simply out of
convenienc
Guido van Rossum wrote:
> On Feb 20, 2008 12:39 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> On Feb 20, 2008 12:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
I agree, the name is a bit confusing when you're not used to it.
>>> Renaming it is easy. To the native speakers reading it: Wha
> > Renaming it is easy. To the native speakers reading it: What should
> > it be called? (please try to come up with something shorter than
> > "request for enhancement")
> >
>
> "feature request"?
How about calling it just "enhancement"?
___
Pytho
On Feb 20, 2008 12:39 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Feb 20, 2008 12:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > I agree, the name is a bit confusing when you're not used to it.
> >
> > Renaming it is easy. To the native speakers reading it: What should
> > it be cal
> It must have changed since I last looked at a feature request on the
> tracker - using a type rather than keyword is fine by me.
I'm fairly certain the rfe type was there ever since the switchover
(at least that's what subversion says: the rfe type was added along
with all other types in r52825
On Feb 20, 2008 12:36 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I agree, the name is a bit confusing when you're not used to it.
>
> Renaming it is easy. To the native speakers reading it: What should
> it be called? (please try to come up with something shorter than
> "request for enhan
> I agree, the name is a bit confusing when you're not used to it.
Renaming it is easy. To the native speakers reading it: What should
it be called? (please try to come up with something shorter than
"request for enhancement")
> Also I find that, by definition, RFE and feature requests are not
>
Martin v. Löwis wrote:
>>> Problem is, we don't have an 'rfe' keyword anymore :)
>>>
>> Shall we grow one again?
>
> What's wrong with the rfe type? Why does it have to be a keyword?
It must have changed since I last looked at a feature request on the
tracker - using a type rather than keyword i
On Wed, Feb 20, 2008 at 8:40 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > What's wrong with the rfe type? Why does it have to be a keyword?
>
> For one it's the name. Personally I didn't know the meaning of RFE until
> I googled it.
>
I agree, the name is a bit con
Martin v. Löwis wrote:
> What's wrong with the rfe type? Why does it have to be a keyword?
For one it's the name. Personally I didn't know the meaning of RFE until
I googled it.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
On Feb 18, 2008, at 1:21 PM, Jeroen Ruigrok van der Werven wrote:
> A bug tracker is a much better way of registering such information.
> It also
> can be easier referenced in the future since even though when it is
> closed,
> the debate and other stuff will remain in the tracker's tickets for
2008/2/19, "Martin v. Löwis" <[EMAIL PROTECTED]>:
> >> Problem is, we don't have an 'rfe' keyword anymore :)
> >
> > Shall we grow one again?
>
> What's wrong with the rfe type? Why does it have to be a keyword?
For me, none. I'm just trying to converge the mail thread to a result, :)
As far as
>> Problem is, we don't have an 'rfe' keyword anymore :)
>>
>
> Shall we grow one again?
What's wrong with the rfe type? Why does it have to be a keyword?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
> We really do need to write some of this down in an information track PEP
> so we're all using the same values to mean the same thing...
There is actually an official meaning to pending: An issue marked
pending will get automatically closed by the tracker after some period
of time (which used t
On Feb 19, 2008 12:22 PM, Facundo Batista <[EMAIL PROTECTED]> wrote:
> 2008/2/19, Georg Brandl <[EMAIL PROTECTED]>:
>
> > Problem is, we don't have an 'rfe' keyword anymore :)
>
> Shall we grow one again?
Isn't the RFE type field enough?
> What would happen with PEP 42? will it be deprecated?
I
Facundo Batista wrote:
> What would happen with PEP 42? will it be deprecated?
It seems 42 isn't the answer at all. What a shame. *scnr* :)
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
2008/2/19, Georg Brandl <[EMAIL PROTECTED]>:
>
> Problem is, we don't have an 'rfe' keyword anymore :)
>
Shall we grow one again?
What would happen with PEP 42? will it be deprecated?
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Nick Coghlan schrieb:
> Brett Cannon wrote:
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
>
> That's a problem with our status reporting, not with the fact that there
> are RFE's
On Tue, Feb 19, 2008, Nick Coghlan wrote:
> Brett Cannon wrote:
>>
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
>
> That's a problem with our status reporting, not with the fact
Christian Heimes wrote:
> Steve Holden wrote:
>> There there's the Status field. I understand "open" and "closed", but
>> what's the semantic of "pending". Is it awaiting triage, awaiting status
>> assignment, or what?
>
> I've used pending for two states. For one I've put an issue on pending
>
Brett Cannon wrote:
> My issue with keeping the RFEs in the tracker as they are is that it
> artificially inflates the open issue count. Python does not have over
> 1,700 open bugs.
That's a problem with our status reporting, not with the fact that there
are RFE's in the issue tracker ;)
Adding
On 2/19/08, Virgil Dupras <[EMAIL PROTECTED]> wrote:
> closed_status = db.status.lookup('chatting')
Oops, replace 'chatting' with 'closed'
Virgil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
On 2/19/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > No, I don't, which is why I would find it interesting to run some
> > queries on the roundup database to have completion statistics for low
> > activity tickets. Is is possible to get a copy of that db somehow?
>
> I would rather not make
Steve Holden wrote:
> There there's the Status field. I understand "open" and "closed", but
> what's the semantic of "pending". Is it awaiting triage, awaiting status
> assignment, or what?
I've used pending for two states. For one I've put an issue on pending
state when it was fixed on the trun
> No, I don't, which is why I would find it interesting to run some
> queries on the roundup database to have completion statistics for low
> activity tickets. Is is possible to get a copy of that db somehow?
I would rather not make it available, as it contains certain
privacy-related information
On 2/19/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Well, we have to evaluate the chances of our older tickets to come to
> > completion. I'm of the opinion that ticket getting older have very
> > small chances of ever being completed. RFE for python 2.4 are likely
> > to be irrelevant.
>
> This is still valid? Should we start moving RFEs to this PEP and
> closing their issues in the tracker?
As other have indicated - PEP 42 was a mistake (IMO).
> Or should we try to get more discussion regarding these RFEs? Maybe,
> for example, a weekly digest where the latests RFEs added are se
> Well, we have to evaluate the chances of our older tickets to come to
> completion. I'm of the opinion that ticket getting older have very
> small chances of ever being completed. RFE for python 2.4 are likely
> to be irrelevant.
Do you have any facts to base this theory on?
Two years for a bug
[Steve Holden]
> I appreciate the desire to "keep the issue tracker clean", but I think
> human intelligence needs to be applied to the task, not just a
> date-based cutoff.
I concur. The older bug reports are ones that have survived
past human-based clean-up efforts. They were left open as
a
On 2/18/08, Steve Holden <[EMAIL PROTECTED]> wrote:
> I appreciate the desire to "keep the issue tracker clean", but I think
> human intelligence needs to be applied to the task, not just a
> date-based cutoff.
Personally, the bug count doesn't bother me. I was just responding to
Brett's concerns
Virgil Dupras wrote:
> On 2/18/08, Steve Holden <[EMAIL PROTECTED]> wrote:
>> I'm not sure we should be throwing RFE's away with such casual abandon
>> just because nobody had time to pay them any attention in six months -
>> nor bugs neither, come to that.
>
> Well, we have to evaluate the chance
Steve Holden schrieb:
> Jeroen Ruigrok van der Werven wrote:
>> -On [20080218 21:41], Brett Cannon ([EMAIL PROTECTED]) wrote:
>>> My issue with keeping the RFEs in the tracker as they are is that it
>>> artificially inflates the open issue count. Python does not have over
>>> 1,700 open bugs.
>>
>
On 2/18/08, Steve Holden <[EMAIL PROTECTED]> wrote:
> I'm not sure we should be throwing RFE's away with such casual abandon
> just because nobody had time to pay them any attention in six months -
> nor bugs neither, come to that.
Well, we have to evaluate the chances of our older tickets to come
> > Which is why I propose to have a mechanism to close bugs and RFE
> > nobody cares about. over *1000* out of those 1700 open issues are 6+
> > months old.
> >
> I'm not sure we should be throwing RFE's away with such casual abandon
> just because nobody had time to pay them any attention in six
Virgil Dupras wrote:
> On 2/18/08, Brett Cannon <[EMAIL PROTECTED]> wrote:
[...]
>> So I have no issue with keeping the RFEs in the tracker, at some point
>> I do want to change how they are represnted so that they are a
>> separate things from issues representing bugs and patches.
>>
>> -Brett
>
Jeroen Ruigrok van der Werven wrote:
> -On [20080218 21:41], Brett Cannon ([EMAIL PROTECTED]) wrote:
>> My issue with keeping the RFEs in the tracker as they are is that it
>> artificially inflates the open issue count. Python does not have over
>> 1,700 open bugs.
>
> An issue does not necessaril
On 2/18/08, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> > Jeroen Ruigrok van der Werven wrote:
> > > -On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
> > > >Personally, I think that a bug tracker is a good place
> > >
> > > PEP: -1
> > > tracker: +1
> >
> > I agree. Then we can set some status/keyword when the subject of a RFE
> > is accepted by core developers, saying "if someone proposes a patch,
> > it has a chance to be reviewed and applied".
> > It may incite occasional contributors to work on some of
-On [20080218 21:41], Brett Cannon ([EMAIL PROTECTED]) wrote:
>My issue with keeping the RFEs in the tracker as they are is that it
>artificially inflates the open issue count. Python does not have over
>1,700 open bugs.
An issue does not necessarily mean the same as bug. :)
Is it a bug tracker y
On Feb 18, 2008 11:11 AM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Jeroen Ruigrok van der Werven wrote:
> > -On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
> > >Personally, I think that a bug tracker is a good place to keep RFE,
> > >not a PEP. I think that the PEP would ten
Jeroen Ruigrok van der Werven wrote:
> -On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
> >Personally, I think that a bug tracker is a good place to keep RFE,
> >not a PEP. I think that the PEP would tend to be cluttered with RFE
> >nobody cares about forever. So the clutter can never
-On [20080218 13:38], Virgil Dupras ([EMAIL PROTECTED]) wrote:
>Personally, I think that a bug tracker is a good place to keep RFE,
>not a PEP. I think that the PEP would tend to be cluttered with RFE
>nobody cares about forever. So the clutter can never be cleaned unless
>someone takes the respons
On 2/18/08, Facundo Batista <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Don't now if always, or in the last few months where I've been
> following the issues more closely, but I found that are appearing a
> lot of small RFEs in the tracker.
>
> These normally are small but not trivial things. In most case
Hi!
Don't now if always, or in the last few months where I've been
following the issues more closely, but I found that are appearing a
lot of small RFEs in the tracker.
These normally are small but not trivial things. In most cases when I
read them I think "Mmm, yes... it won't hurt to have it, b
87 matches
Mail list logo
