All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: Bugzilla
Date: Thu, 19 May 2005 06:25:44 +0000	[thread overview]
Message-ID: <20050319174457.202c104a.khali@linux-fr.org> (raw)
In-Reply-To: <3Xg1uAGB.1110214165.5308430.khali@localhost>

Hi all,

> > Would it be possible to tell Bugzilla to start at ticket #2000? That
> > way the new tickets wouldn't overlap with the older ones.
> 
> Yes, that's possible.
> 
> Is other than that the bugzilla instance OK?

Just taking a closer look to make sure, and in fact I don't think so. In
the current setup, we still have different versions for each "product",
were products are "bus drivers", "chip drivers", "i2c core drivers" and
"user-space". It makes very little sense to me. All these are parts of
the same product, and versions are common to all these parts. Isn't it
possible to do that? I think I remember this was discussed already but I
cannot remember the outcome.

Other than that, I would ask for:

* Less priorities. 7 priorities is too much. I think we could get rid of
blocker (critical will do), trivial and enhancement (minor will do).

* No target milestone. I see little use for these in our project.

* No OS. It is a Linux-only product anyway.

* No priority. Priorities might make sense when people are paid for
support. We are not. We fix things when we feel like it.

* No status whiteboard. What is it for?

* No bug aliases. No use.

Do we need a QA contact? Again, sounds overkill for our project.
Assignee should be sufficient.

What is the URL for? Can't users just include URLs in their comments if
they need to?

I guess you've understood that what I really want is that we keep things
as simple as possible. 10 needless fields are likely to frighten the
users and potential helpers. If we can stick to what is really needed,
I'd expect the support to be easier for everyone.

Thanks,
-- 
Jean Delvare

  parent reply	other threads:[~2005-05-19  6:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  6:25 Bugzilla Jean Delvare
2005-05-19  6:25 ` Bugzilla Axel Thimm
2005-05-19  6:25 ` Bugzilla Philip Edelbrock
2005-05-19  6:25 ` Jean Delvare [this message]
2005-05-19  6:25 ` Bugzilla Jean Delvare
2005-05-19  6:25 ` Bugzilla Axel Thimm
2005-05-19  6:25 ` Bugzilla Axel Thimm
2005-05-19  6:25 ` Bugzilla Jean Delvare
  -- strict thread matches above, loose matches on Subject: below --
2009-02-13 13:10 Bugzilla Graeme Fowler
2009-02-13 22:15 ` Bugzilla Simon Horman
2009-02-14  9:49   ` Bugzilla Graeme Fowler
2009-02-15 15:08     ` Bugzilla Graeme Fowler
2009-02-15 22:18       ` Bugzilla Simon Horman
2008-04-29 10:53 Bugzilla Philip Balister
2008-04-29 12:00 ` Bugzilla Leon Woestenberg
2008-04-29 17:30 ` Bugzilla Rolf Leggewie
     [not found] <1042750169.686.6.camel@tux.rsn.bth.se>
     [not found] ` <1042752014.688.12.camel@tux.rsn.bth.se>
2003-01-16 23:50   ` bugzilla Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050319174457.202c104a.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.