On Mon, Feb 25, 2008 at 06:02:59AM +0100, Lucas Nussbaum wrote:
For many users of other bug tracking systems such as bugzilla, the
meaning of priority vs severity is totally unclear. I don't think that
it would be a good idea to impose such a thing to all packages by
default.
Well, you don't
On Sun, Feb 24, 2008 at 11:58:49AM -0800, Don Armstrong wrote:
It almost sounds like you want a user setable severity-like field.
That could be implemented, but the problem is that it's far less
flexible than usertags because it would only have a single value.
(Note that I did not ask for
* Stefano Zacchiroli [EMAIL PROTECTED] [2008-02-26 12:00:25 +0100]:
Yes, it would be less flexible, but what meaning has a priority field
with multiple values? I think that such a field would be meaningful only
to sort upon it, and go looking for sorting of multiple valued fields
seems to be
On Tue, 26 Feb 2008, Stefano Zacchiroli wrote:
I think that such a field would be meaningful only to sort upon it,
and go looking for sorting of multiple valued fields seems to be
looking for trouble to me.
Since tags don't sort, they segregate, you just choose based on the
first one that
DN don't have the time (or often the ability) to go back and
DN reproduce the hundreds of bugs
Yes. Never mind the old bugs then. Just try to reproduce new bugs as
they come in, before they become old bugs.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
On Thu, Feb 21, 2008 at 11:31:32PM -0600, John Goerzen wrote:
Here are some things that occur to me quickly:
I'll be just pointing to existing tools I'm aware of that are related to
your points. People probably already know all of them, but since I'm a
bit surprised to not having them mentioned
On Fri, Feb 22, 2008 at 05:19:50PM +0100, Roland Mas wrote:
Now, if I could run an 'apt-get source -t unstable foo' and create
my patch against the resulting source package, and be sure that the
maintainer won't reject it on the grounds of the patch not being
against the head (or latest,
On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote:
If there are sets of usertags which are in common use by a reasonable
number of diverse packages, and are something that would normally be
put on the [EMAIL PROTECTED] user (that is to say, make them
visible by default) then file a
On Sun, 24 Feb 2008, Stefano Zacchiroli wrote:
On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote:
If there are sets of usertags which are in common use by a reasonable
number of diverse packages, and are something that would normally be
put on the [EMAIL PROTECTED] user (that is
On 24/02/08 at 20:41 +0100, Stefano Zacchiroli wrote:
On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote:
If there are sets of usertags which are in common use by a reasonable
number of diverse packages, and are something that would normally be
put on the [EMAIL PROTECTED] user
On Thu, Feb 21, 2008 at 11:19:14PM -0800, Steve Langasek wrote:
On Thu, Feb 21, 2008 at 11:31:32PM -0600, John Goerzen wrote:
Excellent points made by both of you.
Here are some things that occur to me quickly:
1) Large projects using $DVCS and making it easy for people that aren't
On Fri, Feb 22, 2008 at 10:51:42AM +0100, Josselin Mouette wrote:
Le jeudi 21 février 2008 à 23:31 -0600, John Goerzen a écrit :
5) A way of sorting bugs by hack on this first. Our priorities are not
necessarily this way. For instance, we may have a wishlist bug to package
the new
On Sat, Feb 23, 2008 at 06:50:00AM +0800, [EMAIL PROTECTED] wrote:
Be sure that somebody looks at new bugs.
As days pass, the test conditions in the report e.g., URLs, deteriorate.
As weeks pass, the user may have removed the package for another.
As months pass, the user may no longer be
On Sat, 23 Feb 2008, David Nusinow wrote:
If those who make heavy use of usertags could get together and form
some sort of consensus standard so that outsiders to the team could
find out common information without having to hunt down the team's
specific documentation, it'd help enormously.
If
Le vendredi 22 février 2008 à 08:33 -0500, Roberto C. Sánchez a écrit :
Now, if I could run an 'apt-get source -t unstable foo' and create my
patch against the resulting source package, and be sure that the
maintainer won't reject it on the grounds of the patch not being against
the head (or
Roberto C. Sánchez, 2008-02-22 08:33:17 -0500 :
[...]
Now, if I could run an 'apt-get source -t unstable foo' and create
my patch against the resulting source package, and be sure that the
maintainer won't reject it on the grounds of the patch not being
against the head (or latest, or
Be sure that somebody looks at new bugs.
As days pass, the test conditions in the report e.g., URLs, deteriorate.
As weeks pass, the user may have removed the package for another.
As months pass, the user may no longer be working on related projects.
As years pass, the user himself might have
[EMAIL PROTECTED] writes:
Be sure that somebody looks at new bugs.
The fundamental problem here that people are trying to express is that,
given our absence of paid staff who are willing to do anything they're
assigned to do, it is impossible to be sure that anyone in Debian does
any specific
On Fri, Feb 22, 2008 at 05:19:50PM +0100, Roland Mas wrote:
Roberto C. Sánchez, 2008-02-22 08:33:17 -0500 :
[...]
Now, if I could run an 'apt-get source -t unstable foo' and create
my patch against the resulting source package, and be sure that the
maintainer won't reject it on the
[ subject changed ]
On Thursday 21 February 2008 8:22:49 pm Don Armstrong wrote:
On Thu, 21 Feb 2008, David Nusinow wrote:
We could deal with this problem if we were better at training and
recruiting people to work on such things. We've been lucky in the
XSF lately in getting enough hands
On Thu, Feb 21, 2008 at 11:31:32PM -0600, John Goerzen wrote:
Excellent points made by both of you.
Here are some things that occur to me quickly:
1) Large projects using $DVCS and making it easy for people that aren't
familiar with $DVCS to learn how to participate in that project. Here
21 matches
Mail list logo
